OO Factory


Oliver,

One of your questions posed in your reply was "Did you mean to post this to comp.lang.cobol". You're damn right I did !.

Sequence - originally following up on my query about Factory thought I'd post to javahelp asking for comment so I created a DRAFT. Then I saw you answering topics in javahelp. So now I took my original DRAFT and hacked it around; of course, lengthy, I saved it from time to time. Spellchecked and sent. Strange - I don't see it popping up on c.l.c. - **$#!!** computers. It was gone from my Draft folder; I MUST have sent it. Only this morning, having rechecked sent messages - confirmed I HAD sent it - to JAVA HELP !!!!

So the original for just the COBOL audience, and then I'll get back to responding to your immediate queries.

Jimmy

*>------------------------------------------------------------------------------------

OK Oliver,

The original draft of this was written to quiz java.help - but I was still thinking I would be SOL, like the response I got from the 'theory' boys in comp.lang.object. Then when I spot your name in java.help - "Here's somebody in a half-way house between Java and COBOL".

Most importantly - COBOL 2002 does have FACTORY - so I'm not on a crusade to revamp the standard and get it deleted. Just trying to check if I'm missing something. The fact that FACTORY exists in COBOL does no harm, even if you don't use it.

Your reference to Gang of Four - obviously nothing to do with the folks in Bejing who are all in a mausoleum by now. If I'm on the same wavelength, is that rather "the Gang of Six", the small software house in UK, with some lucrative government contracts where they appear to have developed SPRING as an enhancement of SWING ? Doesn't matter - but is a book by two of them which triggered this query.

Having got a response from Oliver, please anybody else, jump in and comment. Stephen G. and Simon T., your respective skills are associated I think primarily with Unix and DBs. Perhaps Stephen could point out this thread to one of the OO people, perhaps David Sands, just in case he/they would like to put in their two cents ?

Oliver, I know you have the Java background and by showing up here you have an interest in COBOL. I'm working on the assumption that you are not necessarily comfortable with our OO - so up front I'm spelling out things which you may already know about OO COBOL. I may make reference to Class-Control in examples - this is the syntax used by N/E up to V 3.1; N/E 4.0 onwards uses the J4 Standard 'Repository". Can't actually recall, but I think Fujitsu had 'Repository' from Day One.

Basic outline of a class source :-

*>---------------------------------------------------------------------
Class-id.    MyClass inherits from Base.*> Very much like Program-id.

Class-Control. MyClass is class "myclass"
CustomerFile is class "filecust"
CustomerDialog is class "dlgcust"
.
*> above is listing Classes for which this program/class will initiate *>'instances' for reference.

*>--------------------------------------------------------------------
FACTORY. *> This is class source Item (a)
*>----------------------------------------------------------------
working-storage section.

a series of Factory methods

END FACTORY.
*>----------------------------------------------------------------
OBJECT. *> This is class source Item (b)
*>---------------------------------------------------------------
working-storage section.

a series of Instance methods

END-OBJECT.
*>--------------------------------------
END CLASS MyClass.
*>-------------------------------------

***** Back to the very first line Class-id. For Net Express = "Base" for IBM Enterprise = "JavaBase" and for Fujitsu = "FjBase"


Permutations - you can have :-
Items (a) and (b)
Item (a) only, or
Item (b) only

Based on what Arranga/Coyle gave in their source examples I went with this format using Item (a) :-

*** Before somebody quizzes, N/E prior to N/E V 4 had OBJECT-STORAGE SECTION rather than the current WORKING-STORAGE SECTION - so I got into the habit of prefixing my objects with "os-......" to identify them.

*> for consistency in coding style I stipulate all my Working-storage objects as follows :-

WORKING-STORAGE SECTION.
01 os ThisClass            object reference value null.

For brevity I'll leave out the 'value null'


Example 1
------------------------------------------------
CLASS-A.
--------
WORKING-STORAGE SECTION.
01 os-ClassB        object reference.
PROCEDURE DIVISION - methods.
invoke ClassB "new" returning os-ClassB

CLASS-B
-------
FACTORY.
Method-id. "new".
Linkage section.
01 lnk-self            object reference.
Procedure Division returning lnk-self.
  invoke self "new" returning lnk-self
End Method "new".
------------------- end Example 1 -----------------------------

Above works fine; regardless of the way you do it that "new" method finishes 'climbing' up to class Base to actually create the object.

But then I wanted to pass my MainApplicationWindow plus the DialogRsourceFile to invoked programs/classes from the Master Menu. So Example 1 above slightly modified :-

Example 2
------------------------------------------------
CLASS-A. - Let's assume this is my MainAppWindow - and in a trigger program I've already got object references to os-Parent via desktop and the ResourceFile
--------
WORKING-STORAGE SECTION.
01 os-ClassB object reference.
01 os-Parent object reference. *> as used here = 'SELF'
01 os-Resource object reference.

PROCEDURE DIVISION - methods.
invoke ClassB "new"
       using self, os-Resource returning os-ClassB

CLASS-B
-------
FACTORY.
Method-id. "new".
Linkage section.
01 lnk-Parent            object reference.
01 lnk-Resource            object reference.
01 lnk-self            object reference.

Procedure Division
    using lnk-Parent, lnk-Resource returning lnk-self.

  invoke self "new" returning lnk-self
  invoke lnk-self "passObjects" using lnk-Parent, lnk-Resource

End Method "new".
----------------
OBJECT. *> the 'Instance'
---------------
working-storage section.
01 os-Parent            object reference.
01 os-Resource            object reference.
--------------------
Method-id. "passObjects".
Linkage section.
01 lnk-Parent            object reference.
01 lnk-Resource            object reference.

Procedure Division using lnk-Parent, lnk-Resource.
    set os-Parent to lnk-Parent
    set os-Resource to lnk-Resource

End Method "passObjects".
------------------- end Example 2 -----------------------------

As you can see in the Instance I now have references to Parent and Resource which can be referenced from within any Instance methods.

Now any proficient COBOLer, even if not familiar OO COBOL will look at the above and say to himself, 'What a load of codswallop to get the objects where you want them".

Prior to N/E 4.0 there was only Help from the on-line help - a feature I'm not wild about, finding yourself diverted to other references all over the place. M/F then produced a separate on-line Book on OO. So although I don't have 4.0 ($$$$$$), I am able to read the books and looked for OO differences or any extensions - one of which is Multi Inheritance part of the J4 Standard.

I'm reding the text and 'discover' that you can have a class without any FACTORY for "new". I quickly dash off an e-mail to two M/F users Simon and Calin plus Donald and Will Price. Donald is using Fujitsu and replies "Never used Factory". And Will Price replies, "Look at my second edition of 'Elements of OO'". Oops ! missed Will's reference when checking it for updates from the first edition. Immediately I know which direction I'm going to replace the 'codswallop' :-

Example 3
------------------------------------------------
CLASS-A. - Let's assume etc.....
--------
WORKING-STORAGE SECTION.
01 os-ClassB    object reference.
01 os-Parent    object reference. *> as used here = 'SELF'
01 os-Resource    object reference.

PROCEDURE DIVISION - methods.
invoke ClassB "new" returning os-ClassB
invoke os-ClassB "begin" using self, os-Resource

*> could be making additional invokes of os-ClassB as necessary,
*> after the "begin" above which could be an 'Initializer'

CLASS-B
-------
*>FACTORY.

*> FACTORY completely commented out and NO methods

*>END FACTORY
----------------
OBJECT. *> the 'Instance'
---------------
working-storage section.
01 os-Parent            object reference.
01 os-Resource            object reference.
--------------------
Method-id. "begin".
Linkage section.
01 lnk-Parent            object reference.
01 lnk-Resource            object reference.

Procedure Division using lnk-Parent, lnk-Resource.
    set os-Parent to lnk-Parent
    set os-Resource to lnk-Resource

*> could stop at this stage which would return to ClassA;
*> alternatively start doing methods within ClassB

End Method "begin".
------------------- end Example 3 -----------------------------

As you can see finishes up with exactly the same result as Example 2, but with the shortcut.

Well it worked - and it sure looked to me like Factory was superfluous.
Just last few days re-read the paperback Raymond Obin produced on behalf of the OCTG about OO. Following his index through for references to FACTORY I couldn't find an justifiable case for Factory; the only significant comment was, "Not all OO languages have a Factory". Well COBOL does, so does Java but not Smalltalk for instance; in her text for 'Smalltalk-80', Adele Goldberg shows creation of instances as being as simple as :-

    OrderedCollection new

So currently I'm working without FACTORies. A short time to kill, while my van is being fixed, kill time browsing in Chapters. Considerably fewer books than there used to be prior to Y2K. However one on 'Swing" and next to it 'Spring'. Vaguely know what 'Swing' is about, so I browse 'Spring'. Appears it is written by co-authors and possibly part of your Gang of Four/Six reference above. Little time for it all to sink in but I got the gist - Factory is OK but does have its limitations and if you need additional features you may be faced with a re-compile - ( my reaction - DEAD UGLY !). This I liked for terminology - you can consider Factory as being used for a SINGLETON INSTANCE.

Finalizing in Net Express - it comes up in next paragraph. I believe Fujitsu does have some auto garbage collection as does IBM Enterprise - because the latter invokes JavaBase to control both creation and destruction of objects. M/F came up with an interim - developers we have to finalize our own objects using following methods :-

"finalize"
"deepFinalize"           to a depth of 1
"deepFinalizeWithDepth" 'n' dimensional collection/dictionary

- you'll love the next one,

"reallyDeepFinalize"

Meanwhile of course J4 has produced their TR on 'Finalizer' - the objective being to relieve developers of specifically having to destroy objects and let auto garbage collection do it a la Java and the rest.

OK on the Finalizers ?

Now I can do one of the things with classes (a) Have all methods in Factory and treat it as a 'Singleton Instance' or (b) totally ignore the Factory and create an Instance which has its methods.

Singleton Instance :-

Having used the STRING END-STRING syntax on the message text I can then

invoke ErrorMessages "showmessage"
       using     os-Parent ws-MessageParams
       returning lnk-response

All methods for class ErrorMessages above are in Factory :-

"showmessage" invokes self for "SetTheButtons", "SetTheMessage", "setTheTitle". "setTheType"

I do NOT need to do any Finalizing on this invoke. Similarly, perhaps the most commonly used class in N/E is probably CharacterArray provided by Micro Focus :-

 invoke CharacterArray "withlengthvalue"
   using ls-length ls-Text returning ls-String (ls-string is an object)

and the reverse say from something keyed into a GUI :-

   invoke Dialog-Object "getText" returning ls-string
   invoke ls-string "trimblanks" returning ls-string
   invoke ls-string "getValueWithSize"
       using ls-Length returning ls-text
   *> not shown in this extract but I could use the intrinsic function
   *> to ensure it is valid numerics, as appropriate
   invoke ls-string "finalize" returning ls-string

The CharacterArray is not confined to GUI-Objects, it can be used with Collection objects you want to pass around. But note its invocation - it is a Singleton Instance again, which doesn't require finalization.
*>-------------------------------------------------------------------

There we go Oliver. I'm primarily using only Instance Objects, that singleton for ErrorMessages - am I missing out on the subtleties of FACTORY ?????

Jimmy, Calgary AB

*>----------------------------------------------------------------------------
.