Re: OO Factory

Chuck Stevens wrote:
"Oliver Wong" <owong@xxxxxxxxxxxxxx> wrote in message news:0gIhf.132167$S4.60745@xxxxxxxxxxx


So you're saying that COBOL 2K2 has a "FACTORY" keyword (what it does I'm not entirely sure yet), but you're NOT using it in your implementation?


Strictly speaking, ISO/IEC 1989:2002 syntax allows the FACTORY paragraph (alongside the CLASS-ID, FUNCTION-ID, INTERFACE-ID, METHOD-ID, OBJECT, OPTIONS and PROGRAM-ID paragraphs) in the IDENTIFICATION DIVISION. The only clause in the standard for the FACTORY paragraph is the IMPLEMENTS clause, and it specifies the names of the interfaces that are implemented by the factory object of the containing class.

-Chuck Stevens

Not being snarky Chuck, but above left me in mid-air. I can't confirm that following is 100% conforming to J4 Standard, but for Oliver's info., here is what the N/E 4.0 on-line manual illustrates :-

*>------------------------------------------------------------------------
Interface Source Elements

You write your interface definitions in interface source elements. An interface source element can contain one or more interface definitions.

The code block below shows the outline of an example interface source element. An ellipsis (...) shows where code has been omitted, and indentation indicates the levels of nesting. In this example the interface Drivable, containing a method prototype for calculating mileage, inherits from the interface Rentable, which can be assumed to contain methods applicable to all objects that can be rented.

 interface-id. Drivable
       inherits from Rentable. *> Interface identification.

 environment division.         *> Environment division
                               *> header is optional.
 ...

configuration section.
repository. *> Repository paragraph
*> names the interfaces this
*> interface refers to.
interface Drivable *> Information for the
*> Drivable interface stored *> in the external repository
*> under the name "DRIVABLE"
interface Rentable as "rble" *> Information for the
*> Rentable interface stored
*> in the external repository
*> under the name "rble".

 .                             *> Period ends paragraph.
 procedure division.
     method-id. "calcMileage". *> Start of method
                               *> prototype "calcMileage".
                               *> Method contains data
                               *> but no code.
     data division.
         linkage section.
         01  endMileage  pic 9(6).
         01  beginMileage  pic 9(6).
         01  mileage pic 9(6).
         procedure division using endMileage, beginMileage
                            returning mileage.
         end method "calcMileage". *> End of method prototype.
     method-id. "logDamage".   *> Start of method
                               *> prototype "logDamage".
     end method "logDamage".   *> End of method prototype.


 end interface Drivable.



Interface Implementation

Factory objects and instance objects within classes can implement interfaces. The implementing object implements all the method prototypes defined for the implemented interface definition or definitions, including any method prototypes that the implemented definition or definitions inherited.

Here is an example of an instance object that implements the Drivable interface:

 class-id. Car inherits from Vehicle.

configuration section.
repository.
    class Car
    class Vehicle
    interface Drivable
    .

 factory.
* The code for the factory object starts here
....
* The code for the factory object ends here.
 end factory.
*-----The instance object code starts here.
 object. implements Drivable.
 working-storage section.  *> Instance data goes here.
 ...
 procedure division.
 interface-methods.        *> Start of implementation
                                *> of interface methods.
     method-id. "calcMileage".
     data division.
     linkage section.
     01  endMileage  pic 9(6).
     01  beginMileage  pic 9(6).
     01  mileage pic 9(6).
     procedure division using endMileage, beginMileage
                        returning mileage.
     subtract endMileage from beginMileage giving mileage.
     end method "calcMileage".
     method-id. "logDamage".
     ...
     end method "logDamage".
     method-id. "pickUp"   *> Implementation of method
     ...                   *> inherited by Drivable from
     end method "pickUp"   *> Rentable

 instance methods.     *> start of instance methods
                       *> for an object of this class
     ...
 end object.
*-----the instance object code ends here.
 end class Car.

The Compiler provides conformance checking for interface implementation. It checks that the interface of the factory object of the implementing class conforms to the interfaces to be implemented by the factory object, and that the interfaces of the instance objects of the implementing class conform to the interfaces to be implemented by the instance object. The Compiler also checks that you have implemented all the methods listed in the interface definition. For more information about conformance see the section Conformance in the chapter Using Objects in Programs.
Parameterized Interfaces

A parameterized interface is a skeleton interface that has one or more formal parameters. When you provide specific class names or interface names as actual parameters, the Compiler expands the parameterized interface into a new non-parameterized interface. The purpose of parameterized interfaces is to make it easier for you to create many similar interfaces.

A parameterized interface always has a USING phrase that lists the formal parameters in its Interface-ID paragraph.

You need to specify the EXPANDS phrase in the entry for the interface in the Repository paragraph in any program that uses a interface created from a parameterized interface.

Here is an outline of the code for a parameterized interface:

interface-id. pinterface using fparam1 fparam2.

repository.
    class fparam1
    class fparam2.

method-id meth1.
procedure division using by reference fparam1.
end method meth1.

method-id meth2.
procedure division using by reference fparam2.
end method meth1.
end interface pinterface.

At compile time all occurrences of fparam1 and fparam2 are replaced by the names of actual classes or interfaces. To make this happen you need to specify the ACTUAL-PARAMS Compiler directive. In this example the directive might be:

ACTUAL-PARAMS(MyInterface ClassA ClassB)

MyInterface is the new interface to create from the parameterized interface. ClassA and ClassB are the class names that replace fparam1 and fparam2.

You can now use the MyInterface interface in a class, for example:

class-id. ClassC.
configuration section.
repository.
interface MyInterface expands pinterface using ClassA ClassB
....
factory. implements MyInterface.
....
stop run

You can use the MyInterface interface in a procedural program too, but only indirectly. You need to create a class that implements the interface, then include entries for both the interface and the class in the program's Repository paragraph. In the program you can use typed object references of the MyInterface interface, and use the myInterface interface in object views, for example:

program-id. prog.
repository.
class A.
class B.
class ClassC implements MyInterface.
*> this class implements MyInterface
interface MyInterface expands pinterface
                                   using ClassA ClassB.
....
working-storage section.
1 obj-ref1 usage object reference MyInterface.
1 obj-ref2 usage object reference factory class3.
procedure division.
    set obj-ref1 to obj-ref2
    invoke obj-ref1 "someMethodInTheInterface" using ...

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

And I look at the above and say to myself "KISS" ! I think it's the above sort of tautology that gets OO a bad wrap in the COBOL community.

Oliver without going into the full history it transpired that back around '96 a Russell Clarke in Australia, had submitted a paper for OO collections/dictionaries. My modest guess, he spent at least six months putting his thoughts together in an incredibly well-documented but complex paper. I get the impression that J4 members thought it was so good, they could submit it to ISO for approval. It got hammered by the ISO crowd and then was put on ice. I truly suspect the truth was, with perhaps one or two exceptions, that they, (J4 members), didn't understand it. OO is not your daily bread-and-butter Procedural COBOL.

I only became aware of it years later when Bill K. raised the issue that it was sitting on ice, with a promise it would be resurrected. Again I suspect groans from J4 - they weren't thrilled Bill brought this one up.
Well - I was already reasonably comfortable with the M/F approach to collections/dictionaries, (and even more so now as time moves on). I looked, and looked at Russell's paper - this guy was light years ahead of me in design/thoughts. As the issue had been raised I thought somebody should contribute something, so "Here goes.....", put my thoughts on paper as a discussion document not a set of recommendations.

Part of my process was to contact Russell for background; unfortunately the last e-mail address known was dormant. It was only *just* as I was finishing my piece that Russell picked up on my e-mail. Really too late to stop and re-think I went ahead with my input, acknowledging Russell's late comments to me. (He did acknowledge to me he had forgotten about SortedCollections. Dammit, if J4 didn't do exactly the same thing until I beefed about it !)

As indicated, I really was lost in his technical prowess. It was something you wrote in response to me, in this thread, that triggered the following reflection. Russell was dealing with abstracts; possibly not the correct word but 'proto-typing'. He was giving you a Lego toolkit to put collections/dictionaries together in almost any fashion you liked, (your lists/maps, in Java). Your phrase went something like, "Suppose you don't know which class you want....." - he was going down the same path. Reflecting back to the final lines of his response to me, "...... I've since moved on from COBOL and now I program in Java.....". No wonder I found his document complex - it was obviously from his association with Java that he managed to concoct his abstractness !

As it stands, to my mind doing all that's basically necessary, the J4 Standards TR(Technical Report) on Collections has :-

Ordered Collection
Sorted Collection
Keyed Collection (dictionary/map)
A collection Exception Class
Iterator Class ( in M/F we would refer to that as a Callback)

Above is going from memory - so if I've missed one Chuck or Bill can jump in. From my M/F experience I'm not over enthused with the end result - it lacks a few support classes for character/array handling - which I think each vendor will need to supply - result, portability between compilers goes completely out of the window.

Jimmy, Calgary AB
.