Re: Some OO design principles WAS Re: Differences in data description in programming languages
From: James J. Gavan (jjgavan_at_shaw.ca)
Date: 12/03/04
- Next message: S Comstock: "Re: COBOL III"
- Previous message: William M. Klein: "Re: Infinite Loops and Explicit Exits"
- In reply to: Pete Dashwood: "Re: Some OO design principles WAS Re: Differences in data description in programming languages"
- Next in thread: Pete Dashwood: "Re: Some OO design principles WAS Re: Differences in data descriptionin programming languages"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 03 Dec 2004 04:33:08 GMT
Pete Dashwood wrote:
Pete - Good info - interjections below
>Early binding means that the compiler can resolve much of your OO code when
>you compile it. Late binding means it is resolved at run time. It is similar
>(in concept, not in practice) to static and dynamic linking.
>
>The difference is that the SYNTAX changes (well, it doesn't have to, but
>you have more choices) if you use early binding, and it is, obviously, more
>efficient because there is less to do at run time. If you use the :: in-line
>syntax I believe it is only available with early binding. (To my eye, it is
>ugly in a COBOL program anyway, but that's just me...)
>
>
>
>>>>>>
Well that's got to be me - EARLY binding. Now :-
"If you use the :: in-line syntax I believe it is only available with early binding. (To my eye, it is ugly in a COBOL program anyway, but that's just me...)".
No it's not. Click your memory cells, back in softawaresimple, I wrote to the effect, I didn't like it, and was that what Bill referred to as "C-ifying" the language". You replied something like "Well it's OK Jimmy as long as we don't have to use it....".
Now here's the rub - there's only about three of us "dare" to post OO code here, you, Fredrico and me. Donald is a fourth, but reticent - maybe he's the smart one :-). Now I'm not imagining it, but say roughly 7 to 14 days ago, I'd swear I saw you post something which had those dreaded double colons :-)
Just checked the N/E V 4.0 on in-line invocation, plus as it is lumped together, it covers the next topic. I've just done a copy/paste so I hope it shows up OK your end :
In-line Method Invocation
You can invoke a method in-line, as long as it has a returning
parameter, by coding the object reference followed by the method and
separated by two colons in place of an operand in a statement, for example:
move anAccount::"getBalance" to current-balance
This is equivalent to the following INVOKE statement:
invoke anAccount "getBalance" returning current-balance
**** There's no reference to early/late binding here - so I'm assuming
it is kosher for both
Invocation Using Object Properties
You can invoke get property and set property methods using object
properties. Get and set property methods are methods that are either
generated automatically by the Compiler in response to object property
syntax in data definitions, or coded by you using special syntax in the
Method-ID paragraph. To invoke a get or set property method, you use a
statement such as:
move balance of anAccount to current-balance
This statement invokes the get property method balance of the account
object referred to by the object reference anAccount.
For more details see the section /Get and Set Property Methods/
<http://supportline.microfocus.com/supportline/documentation/books/nx40/opmeth.htm#u040>
in the chapter /Methods/.
Conformance
Conformance is a quality that applies to interfaces. The term interface
is used in two ways in OO COBOL:
* Every object, whether factory or instance, is said to have an
interface consisting of the data and methods that have been
defined for the object in its class source element.
* An interface can also be a collection of method prototypes,
specifying some behavior.
Part of an object's interface (in the first sense) can be a set of
methods that it provides because it implements an interface (in the
second sense). Interfaces in the second sense are explained in more
detail in the chapter /Interfaces/
<http://supportline.microfocus.com/supportline/documentation/books/nx40/opinte.htm>.
It is essential in OO programming that, when your program is executed,
each object conforms to the interface that you defined for it. To help
to ensure this, the Compiler provides conformance checking. In other
words, as far as possible it ensures that your objects will conform at
run-time to the interfaces you have described for them. If any
conformance checks fail, the Compiler displays error messages. The more
rigorously you use the OO COBOL syntax, the more thoroughly your program
will be conformance checked.
Conformance checking relies on the existence of an external repository
file, containing details of all the interfaces. The use of this file is
controlled by the REPOSITORY Compiler directive, as follows:
* To request that your program is conformance checked, compile it
with the setting REPOSITORY (CHECKING ON)
* To make sure information about the object interfaces in your
program is added to the external repository, so that other
programs can be conformance checked against it, compile with the
setting REPOSITORY (UPDATE ON).
* If you want both checking and update, compile with the setting
REPOSITORY (UPDATE ON CHECKING ON).
Here are some examples of the kinds of checks included:
* You invoke a method of an object of class A using a typed object
reference. The Compiler checks that the method exists in the class
and that all the using and returning parameters in the INVOKE
statement match the parameters defined for the method in the class.
* You define class B as inheriting from class A. Class A's factory
object has two methods, and so does class B's. The Compiler checks
that the methods in class B's factory object have the same names
and same using and receiving data definitions as the methods in
class A. (The methods in class B override the methods in class A.)
* You define classes B and C as inheriting from class A, and you set
a typed object reference for class B to a typed object reference
for class A; the Compiler rejects this, because at compile time
the typed object reference to class A might actually point to an
object of class C. (You can get round this restriction by using an
object view, which delays the checking until run time. For more
information see the section /Object Views/
<http://supportline.microfocus.com/supportline/documentation/books/nx40/opusob.htm#u005>.)
The Compiler uses the information in the external repository to perform
conformance checking.
**** Now when it comes to Repository I was going to ask you to confirm , over and above parameter checking, doesn't it check methods - the answer above is "Yes". That to me is far more important than parameter checking.
Most times you will pick up on typos in method names when testing, but it is irritating to have to go back, change and re-compile. Even more irritating as part of the particular tests you are doing, you may hit a 'Private' method that you haven't used before !
(For others reading this - unlike other OO languages COBOL does not distinguish between 'Private' and 'Public' - the difference between the two being, 'Public' you, the external coder, know about them. 'Private' is invoked within something you can't see, (encapsulated) - might be current 'utility' or the super utility above that it inherits from. That's not an insurmountable problem in a large installation - assume the DBA is responsible for both control of the (R)DBMS and installation utilities - he *only* issues you a list of Public methods which you can use and sending/returning parameters required).
>The REPOSITORY (or prototyping) allows the compiler to have acces to all the
>properties and methods of the classes you are using, so it can syntax check
>your invokes and make sure that the right number of parameters, of the right
>type, are declared for the methods.
>
>This feature is of little use to me as I try to minimise the number of
>parameters to methods anyway, for the reasons I outlined in my original
>post.
>
>As I am a late binding fan, it is also pretty irrelevant (for me).
>
>The main advantage of late binding is that you can change the class without
>having to recompile all the programs that use it. If the class is early
>bound it is "integrated" nto the application.
>
>
No don't quite agree with that, but see what you are getting at. Let's
say I've got my own super class - in fact I have - DBIMain (Database
Interface Main) - contains common methods applicable to collections.
Assume I already have 1,000 program that utilize invokes, perhaps
through their own separate DBIs (say CustomerDBI is one) - they each
pick up on methods available in DBIMain such as :-
invoke os-CustomerDBI "getKey" using os-Collection returning ws-CustomerKey
That method is addressed to CustomerDBI, doesn't find it and shoots
straight up to find it in DBIMain. After some five years of happy
OO-coding, we hit a new condition which just doesn't quite fit. We
really need a method which needs to be 'tweaked' - we don't want to
upset the apple-cart, and as you point out, re-compile all the
'senders'. So we have the ability to add an entirely new method to
DBIMain, one compile, and assuming there are three new "senders" just
compile those three.
Not quite the same as I'm illustrating above, but shows how it can be
done. I use the Dialog Editor to "visually" design screens. I use one
copyfile of passing parameters regardless of whether it is a listbox,
dropdown or entryfield etc. I'll stick with entryfield. With the M/F
dlgedit.exe I design, set positioning and tick (Hey ! That's OK in the
USA, heard an American use it on one of the TV channels last night),
against a limited set of properties, "numeric", "disabled", whatever.
Rather than laboriously go through each control as generated in the
....rc file, (Resource File), I set up a sub-parameter class identifying
each control, and the sequence they appear for tabbing, (this contains
fixed format for entries regardless of control type and is "occurs
MaxControls"). Each of the individual table parameter rows are now
passed to an instance of a 'generic' dialog to create them. Fine it works.
Think back some years ago I sent you a screen shot of the 'Readings' - a
two-dimensional table.
No can do with the Dialog Editor, even on a small table it would be
LABORIOUS identifying each 'cell' to a unique name. But I can still use
a row parameter passing technique from that parameter class for dynamic
creation - and for these in the common parameter copyfile I have to
identify x,y, w and h to get positioning.
The obvious and easy way is two separate methods :-
PUBLIC METHODS - "createEntryField" and "createDynamicEntryField" both
receiving lnk-DialogParameters.
Then I look at the code - wait a minute they are both doing the same
thing for an entryfield, except for positioning , where I provide x, y,
w and h for the latter. So still two PUBLIC methods accessing one
PRIVATE method :-
*>--------------------------------------------------------------
Method-id. "zCreateEntryfield".
*>-------------------------------------------------------------
Linkage section.
copy "\copylib\dlgparams.cpy" replacing ==(tag)== by ==lnk==.
Procedure Division using lnk-Params.
invoke self "getObjectFromId"
using lnk-ID returning lnk-object
invoke self "zCreateEntryfield2" using lnk-Params
End Method "zCreateEntryfield".
*>-------------------------------------------------------------
Method-id. "zCreateEntryfield2". *> PRIVATE
*>-------------------------------------------------------------
*> some local-storage fields
Linkage section.
copy "\copylib\dlgparams.cpy" replacing ==(tag)== by ==lnk==.
Procedure Division using lnk-Params.
initialize ws-MethodRec
initialize ls-length
invoke lnk-object "accessSystemEvents"
*> ****** lots of other coding for any entryfield, as appropriate
......
Exit Method.
End Method "zCreateEntryfield2".
*>--------------------------------------------------------------
Method-id. "zDynamicEntryfield".
*>-------------------------------------------------------------
Linkage section.
copy "\copylib\dlgparams.cpy" replacing ==(tag)== by ==lnk==.
Procedure Division using lnk-Params.
invoke TextEntry "new" using self returning lnk-object
invoke lnk-object "SetRectangle" using x y w h
invoke lnk-object "SingleLineEntry"
invoke self "zCreateEntryField2" using lnk-Params
End Method "zDynamicEntryfield".
*>--------------------------------------------------------------
Over and above what I show in "zDynamicEntryField" - it makes sense to
get it right just the once by invoking self. So far I've never had
errors resulting from the above - any errors occurring result from what
I missed in setting up the pre-defined parameter list. (As background to
that - I did have a half-assed attempt to read the dialog resource file,
which obviously is line-sequential, fixed 80 chars, but needs some
fiddling to identify entries for individual controls, depending upon
line-lengths and that's dependent on which properties have been set.
.Let's say, as is, it works some 75% - but with patience I could reach
100% - then I wouldn't inadvertently even get parameter errors).
More on your other comments later - 'cos this was easier to answer.
Jimmy
>Pete.
>
>
>
>
>
>
- Next message: S Comstock: "Re: COBOL III"
- Previous message: William M. Klein: "Re: Infinite Loops and Explicit Exits"
- In reply to: Pete Dashwood: "Re: Some OO design principles WAS Re: Differences in data description in programming languages"
- Next in thread: Pete Dashwood: "Re: Some OO design principles WAS Re: Differences in data descriptionin programming languages"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
