Re: OO Factory(1)

Oliver Wong wrote:
> Crossposted to comp.lang.cobol 'cause I think it'd be more on-topic there.
>
> "James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
> news:p6thf.601829$oW2.508954@pd7tw1no...
> 
>
>
> [snip]
>
>     Wow, that's a long question. I'll have to read through it again (perha
ps
> print it out and mark things up with a traditional pencil) to make sure I
> can follow the whole post, but for now, let me just check if I get the gis
t
> of the question.

Obviously from your initial WOW I threw you a zinger - like it or not,
just as well I spelled out the COBOL syntax. As you mentioned Roedy,
another Canuck had chipped in, I'll go back to javahelp and take a
looksee. (Took a breaks from typing this and see Roedy gave me a
reference to the Gang of Four - I'll take it as read).

>     Are you essentially saying "This is how I've implemented the Factory
> pattern in my COBOL program. Is this the correct approach?" ?

Your question is 'almost' there. Yes that is my Factory 'pattern'
(although I hate the underlying nonsense about the word 'pattern'). No
not, "Is this the correct approach ?". If I totally ignore Factory,
which I am able to do - am I missing features in Factory which 'enhance'
usage, rather than restrict myself solely to instances. Is that any clearer.
>
> 
>
>
>     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?[/color
]

Correct the Standard does have the keyword "FACTORY" as shown in the
class outline. But I was attempting to illustrate how historically I
came ignore it.
>
> In the meantime, I'll try to pick up the "easy" parts of your post and
> address them right away.
>
> 
>
>
>     As Roedy mentioned in another branch of this thread, the Gang of Four
> refers to Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides.
> AFAIK, they essentially invented the concept of design patterns and
> published a book describing what design patterns are, and gave a list of
> useful design patterns. "Factory" is one of the patterns listed in their
> book.
>
> 
>
>
>     Did you mean to post this on comp.lang.cobol?
>
MOST DEFINITELY !
> 
>
>
>     Right, the only dialect of COBOL I know is Liant's RM/COBOL which I
> believe is based on the COBOL '84 standard, so I really don't know anythin
g
> about how OO works in COBOL.

OK, so I've thrown you a zinger. Liant(RM/COBOL) is traditionally
Procedural based. First COBOL I used with Radio Shack Model II and 16s.

> 
>
No specific project in mind, but the approach is intended for any
project. As regards UML as one of the whiz kids at Micro Focus wrote
when I quizzed, just another interesting tool, which  he learned from a
course. Same goes for Rational Rose

Frankly I am a doer. If I want to do something, I'll think it through in
my head, establishing my own 'pattern' or using really old terminology,
a FLOWCHART showing the programs ins and outs. Does the reasoning feel
right. Now can I translate that into code - and by hook or by crook - if
my idea has merit I'll code to make the language, whichever it is, fit
my ideas - not become subservient to some preconceived design patterns.

If the above doesn't sit well with Java readers or even those few
COBOLers who love to wallow in the abstract aspects of OO COBOL, reflect
on the following. COBOL has been around now for some 45 years, in all
probability before fellow Calgarian James Gosling was but a twinkle in
his Daddy's eye.

Way back when, with precious little else around, COBOLers got a handle
on the language. Design Patterns ? The term was meaningless. But
instinctively, in a business sense, they visualized how a business
problem should be handled. Flowchart-wise a rectangle being the
computer, inputs : cards/paper-tape/mag-tape etc., reference :
files-on-tape/files-on-disk, outputs : to disk/tape/printer.

I look at some 'newbies' asking in comp.lang.object, because they've
been inculcated, "You must use design patterns", they feel the necessity
to ask some guru for advice. Well ! First problem for a COBOLer are the
new buzz words being used to describe quite simple features. Get beyond
that barrier, and any decent COBOLer with say 4 years or more at the
language would be inclined to say, "What's the problem ? This is how I
would do it in COBOL....", and he is talking about Procedural COBOL, not OO.
>
>     I don't know what your timeframe is for this project, but if you've go
t
> enough time, you might want to learn UML (Unified Modelling Language),
> especially the Class Diagram part of it.
>
> http://pigseye.kennesaw.edu/~dbraun...orial/class.htm
>
>     The issue is that some of the terms you're using are standard OO terms
,
> so I know what you mean (e.g. "classes", "methods"), while others seem to 
be
> specific to COBOL and I have to guess at their meaning (e.g. the "Factory
> Division" sounds like it might be limited to what Java calls constructors,
> or it might be for static methods in general).
>

Yes I think you are close. Factory is a constructor - a cookie cutter
from which you create your instances. But as I've tried to illustrate,
no matter which way you tackle it, the initial cookie cutting is
initiated at the top of the hierarchy Class Base. I think I mentioned
Smalltalk. They don't have Factory - I tried to find a reference to what
I read, but vaguely from memory there is a Systems Object class, which
in the same pattern as our Class Base - does the parallel function.

So back to Factory usage it is a 'blind' method if you like. invoke
ThisClass "new" from the INVOKER class then the INVOKEE class
understands, even if Factory is not present, that it must 'climb' the
hierarchy up to class Base which does the initial cookie cutting based
on the Class you are referencing.

OK so you can use Factory as a constructor - boils down to what other
uses *could* Factory methods be put to, that I can't achieve within the
Instance coding.

>     UML includes a standard set of terms that is language agnostic, so if 
we
> both use UML to communicate, it'll probably remove a lot of the confusion
> for me.
>
Well based on that I'll give UML a look

> 
>
>
>     Are you saying that the "new" method is defined in the Base class? Do
> you know if in OO COBOL, all methods eventually extend Base if you go up t
he
> hiearchy (i.e. this is a single-root Object hiearchy), or if there might
> possibly be multiple different roots?

Base - "The buck stops here". If you make a typo on the name of an
invoked method, obviously the runtime goes searching, and on failing you
arrive at Base which will generate a runtime error "Class
MyCustomerDialog does not understand message OllieWong", when there is
only a method for 'OliverWong'.

Please remember specifically, I'm talking about Micro Focus support
classes. Yes, there are sub-roots, and an obvious one, GUI classes for
the individual controls report to Class Dependent; that in turn reports
to Base. Dictionaries/Collections, along with some character/array
classes are in a sub-group also reporting to Base. I haven't used them
but I also have a subset on Java, which allows for inter-language
communication. That is in my Version 3.1. If you upgrade to the current
V4.0 compiler - inter-communicatin with any language using dotNet.

I think I can chop out some of my examples for brevity, because I don't
see you raising a question - if I have deleted something containing a
question that you need answering - point it out to me

>
>     Okay, I think I'm still following: "new" is a method in Class-B, and
> when you invoke it, it does some magic (I'm not to clear on what exactly
> happens here in OO COBOL) to put an instance of Class-B into lnk-self. It
> then invokes "passObjects" on that instance which sets up the member field
s
> lnk-Parent and lnk-Resource in the instance.

I think that needs a little explanation to clarify. Seeing as you want
me to look at UML, just out of interest you may want to take a gander at
this on-line book covering the OO feature of Net Express :-

[url]http://supportline.microfocus.com/supportline/documentation/books/nx40/oppubb.htm[
/url]

Three possibilities and I wasn't aware of the third until I accessed the
above on-line book for the first time. In summary :-

"SELF enables an object to send a message to itself. The method invoked
is a method in the same class....."

"SUPER enables an object to send a message to itself. The method invoked
is a method in one of the superclasses of the class...... " It follows
this works its way up through the hierarchical chain.

The next is an M/F extension and not part of COBOL 2002 :

"SELFCLASS enables an instance object to send a message to the factory
object which created it. The method invoked is a method in the factory
object. If you use SELFCLASS from a factory method, it points to the
metaclass for this class, which is an instance of Behavior".

Oops ! Behavior. A class which is immediately subordinate to Class Base
- they more or less work as a pair.

So clarification on that Example 2 - I create an instance of ClassB
(let's just call it ThinggyMeJigObject) and to get it back to the
invoking Class it is returned by that linkage format. Now in Example 2
having got ThinggyMeJigObject, within Factory, I can now invoke
ThinggyMeJigObject ( I called it lnk-self), to do something in a method
of the instance (bearing in mind yet again, it is Base which
acknowledges the "new" method).

Does that help - or do you require further clarification.
 
>
>
>     Yes, so far so good.

Bit difficult to figure out which of us is writing which because both
our texts are showing up blue on white :-). But if the "Yes, so far so
good" is YOU - Great :-)
>
> 
>
>
>     It looks like part of the confusion lies with the fact the FACTORY is
> actually a keyword in COBOL which very precisely define semantics (i.e. it
> makes the compiler behave a specific way), where as "Factory pattern" is
> just a concept in Java, not a keyword. There's many ways to implement the
> Factory pattern in Java just like there's many ways to sort a list.

Yes Factory is a RESERVED WORD intorduced specifically for OO. If you
read me elsewhere, with Chuck's assistance we've narrowed it down to the
fact that OO COBOL has only necessitated the introduction of some 19 new
RESERVED WORDS.

Yes I can understand your refrence to Java Factory as being a 'pattern
maker'.
> 
>
>
>     I was being a bit careless earlier when I said "Factory" is a pattern
> listed in the GoF (Gang of Four) book. Actually, they do not list any such
> pattern. They have "Abstract Factory" and "Factory Method". It sounds like
> the OO COBOL's "FACTORY" keyword is an implementation of the "Factory
> Method" pattern: That is, it's a method whose sole purpose is to create a
> new instance of an object and return it.

I could try and wade my way through the legalese jargon in the Standard,
but let's see how M/F put it in their on-line manual. Well, having read
the following before copying/pasting, and I'm not claiming a victory, it
does appear to give a resounding 'YES you don't need Factory' to my
query. Do you agree. Or is there somebody out there who would disagree ?
I think it worth quoting in full :-

-------------------------------------------------------------------------
Factory Object Data

You declare factory object data in the Working-Storage Section of the
factory source element. Factory object data can be accessed only from
factory methods and can optionally be inherited by a subclass.

When a class is loaded by an application, the run-time system allocates
an area of memory for the data declared in the Working-Storage Section
of the factory source element, and for data declared in any superclasses
it inherits from.

A factory object can only access data directly that it has declared
itself. A factory object can only access data it has inherited by
sending messages to its superclass.

For further information about data inheritance using ISO 2002 OO COBOL
see the section Data Inheritance. For further information about data
inheritance using Micro Focus alternative syntax see the section Data
Inheritance in the chapter Micro Focus OO COBOL Alternative Syntax.
Class Initialization

Class initialization code is executed when the class is loaded by the
run-time system; it is only ever executed once during an application
run. Class initialization code is optional, and for most classes is not
required. You use it for initializing factory object data. For example,
you might want to make certain objects available to your factory object
at startup. You couldn't specify these in value clauses in your factory
Working-Storage Section because value clauses can only specify static
data, whereas object handles are allocated dynamically at run time.

To write class initialization code, write a factory method called
"initializeClass", and put all the initialization code in that method.
The method will be automatically called by the run-time system when it
loads the class.

Your COBOL system uses demand loading to reduce application startup
times. This means you can't predict exactly when any particular class
will be loaded. A class is guaranteed to be loaded and initialized by
the time it receives its first message. Because you do not know exactly
when a class is loaded, you should not rely on class initialization code
to set values in external variables used elsewhere in the application.
Factory Methods

Factory methods are source elements nested inside the factory object
source element. There is only ever one occurrence of any particular type
of factory object when you run an application, so factory methods are
generally concerned with the creation and management of instance objects.

Factory methods have access to factory object data.

You code factory and instance methods in the same way; the only
difference between them is their position in the class source element
and the scope of data to which they have access. Coding methods is
explained in more detail in the chapter Methods.
---------------------------------------------------------------------------

I think at this point I could pack it in. Above indicates what I'm doing
is perfectly acceptable and nothing really in what they say about using
FACTORY turns me that I should think "I MUST use Factory".
>
>     In Java, that concept alone is not so useful, because there exists a
> keyword called "new" which does exactly that. Here's a line of code which
> creates a new instance of ClassB (in Java names can't have dashes in them)
> and stores it in a variable called osClassB:
>
> osClassB = new ClassB();
>
>     Where it becomes more useful is when you're not sure yet what kind of
> object you want to create. Imagine you have a class hiearchy such that you
> have a abstract class "Person" and you have a class "Man" which extends
> "Person" and a class "Woman" which extends person. (I don't know if OO COB
OL
> has abstract classes; an abstract class is basically a class for which you
> cannot create an instance of) In the code, to determine whether an instanc
e
> of a Man or an instance of a Woman, one way to do it is (in Java):
>
> if (gender = 'M') {
>   osPerson = new Man();
> } else {
>   osPerson = new Woman();
> }
>
>     Alternatively, you could replace that with a factory method like so:
>
> osPerson = createPerson(gender);
>
>     This invokes the method "createPerson", passing to it the variable
> "gender". The method will take care of looking at the gender, deciding wha
t
> type of object to create, and then return the newly created instance.
>
>     The different here might seem trivial, but you could imagine a case
> where deciding what object to create were much more complicated, perhaps
> spanning 20 or more lines. Rather than duplicating that decision code, it
> would be better to put it in a single method and invoke it whenever needed.[/color
]

Bearing in mind that until fairly recently, last ten years, there
weren't any OO COBOL compilers - so around '96 onwards for 'desktops' -
IBM Visual Age, geared to OS/2, and for Windows, Fujitsu and Micro
Focus. Since then mainframe - IBM Enterprise which as I indicated does a
nice shuffling aside of the problem by using :-

MyIBMClass inherits from JavaBase

I have no idea of mainframe compiler prices; you can imagine they aren't
cheap. So you don't nip around to the nearest IBM outlet and pick the
latest and greatest up every six months. In my view, from Newsgroup
observation and historical tales from Grace Hopper's era, IBM have
always done 'their own thing'. As part of the operating system they
supply general routines regardless of the language you are using, so
they are in effect in control. Sounds familiar ? Isn't that the same
accusation made against Bill Gates.

So with no mainframe tool to guage how this funny 'OO stuff' works,
mainframers are certainly puzzled. And regardless of how many of us
(people), who are programming for PCs/Unix/Linux , there are (Gartner
survey), BILLIONS and perhpas more BILLIONs of lines of mainframe COBOL
code running Payroll and our internatinal banking systems.

No mainframe tool to experiment with, "Ha Humbug !" retort quite a few
mainframers. In fact some are positively hostile to the concept of OO
and want to sweat out their remaining years continuing to do what they
have been doing for the past 3 or 4 decades.

For certain what you mentioned above gets up their noses, and in fact
gets up mine. It starts with your phrase above, "Where it becomes more
useful is when you're not sure yet what kind of object you want to
create. Imagine you have a class hiearchy such that you  have a abstract
class "Person" and you have a class "Man" which extends etc....".

I recall years ago a COBOLer commenting, having read some text on OO,
and the example was obviously talking about hierarchical structures with
reference to animals, he commented "What have giraffes, elephants and
camels got to do with business programming ?". I sympathized with his
thoughts. Might be useful if I was a zoo keeper and had to feed the
animals at Calgary Zoo.

I think you can get positively esoteric and go off into space about
formulating abstract objects. Still if that's your scene, go for it. I
for one know exactly which objects I want to create, a COBOL file, an
SQL Table, a Dialog, EditProgram or PrintProgram etc.
> 
>
>
>     Just in case you weren't aware, "Singleton" is another design pattern
> from the GoF. It's a way of ensuring that there only exist one single
> instance of a given class at any time.
>
> 
>
>
>     Yeah, I think so. Basically, it sounds like different dialects of OO
> COBOL handle finalization differently.

No different time sequence really. Having done their thing, Micro Focus
knew that auto garbage collection had to be a new feature. So that one
got pounded away at J4 (our Standards Committee) resulting in the
current TR(Technical Report) "Finalizer" to implement auto garbage
collection.
>
> 
>
>
>     It sounds like what COBOL calls "Factory", Java calls "static", and UM
L
> calls "class scope" (as opposed to "instance scope").
>
>     Usually the way Singleton is implemented is (in Java terminology) to
> have a static field which stores the single instance, and to have a method
> which returns it. The code in Java looks like this:
>
> class MySingleton {
>   private static MySingleton soleInstance = null;
>
>   public static MySingleton getSoleInstance() {
>     if (soleInstance == null) {
>       soleInstance = new MySingleton();
>     }
>     return soleInstance;
>   }
>
>   /*Other instance methods may exist here.*/
> }
>
> I'll make a feeble attempt at guessing what the OO COBOL version will look
> like, but recall that this is the first lines of OO COBOL I've ever writte
n:
>
> *> AAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBB
> *>------------------------------------------------------------------
> CLASS-ID. MySingleton INHERITS FROM Base.
>
> CLASS-CONTROL.
> SoleInstance IS CLASS "MySingleton"
> .
>
> FACTORY.
> WORKING-STORAGE SECTION.
> 01 SoleInstance MySingleton OBJECT REFERENCE VALUE NULL.
> METHOD-ID. "getSoleInstance"
> PROCEDURE SECTION RETURNING SoleInstance.
>   IF SoleInstance EQ NULL
>     INVOKE SELF "new" RETURNING SoleInstance
>   END-IF
>   .
> END METHOD "getSoleInstance"
> END FACTORY.
>
> OBJECT.
>   *> Other instance methods may exist here.
> END OBJECT.
> END CLASS MySingleton.
> *>----------------------------------------------------------

As a kindly teacher, I'll give you a 10 out of 10 for that one, coupled
with a Gold Star on your exercise book :). Never thought of it that way,
but the operative line is 'invoke self "new"' - I'm reasonably certain
the compiler would buy your Factory method.

The only thing, no marks deducted, 'cos you didn't know - at least the
M/F compiler would be unhappy with your source filename "MySingleton".
It's damn silly - it expects that as lowercase whereas it will quite
happily accept a mixture of Upper/Lower for method-names, which can also
be written without the quotes around the literal-name.
>
>
>     Whether something requires finalization or not is a very language
> dependent question, I think, and I don't know enough about OO COBOL to
> comment on that.

Ignore finalization Oliver - I merely did it as an intro to show that
'Singleton Instances), i.e. use of Factory only, don't need finalizing.
>
> 
>
>
>     As for whether a Singleton should be used or not for the ErrorMessage,
 I
> would have probably recommended against it and (in Java) told you to use
> static fields and static methods instead. But it sounds like that's what y
ou
> were already doing anyway (since it seems to me that Java statics = OO COB
OL
> Factory).
>
>     It sounds to me that you understand the concepts, but that a lot of
> confusion is arising from the terminology. From what I've read, it really
> sounds like "FACTORY" means "static" or "class-scope", but it seems like a
> very strange choice of name, so we should probably look more into that.
>
>     Maybe someone who has a lot of experience with both COBOL and Java can
> chime in (e.g. Pete Dashwood?)

Possibly he might if it piques his interest, although he is much more
interested in Java at this stage.

Not having N/E 4.0 I only referenced the manual for new features it
might be adding, specifically as regards dotNet and I saw an example of
Multiple Inheritance - yet another 'iffy' in OO languages - some do and
some don't. I didn't read the text from cover to cover - I should have
done - I would have picked up on that Factory quote above - seems to me
as I read it, that I'm a OK, Would have saved this lengthy exchange.

Should we perhaps conclude it here without involving the Java folks. Can
always pursue different topics of OO within c.l.c. as necessary - should
you so wish.

Jimmy, Calgary AB
----------------------------------------------------------------------

Perhaps I should nip over to Quebec for a bite of French cuisine - I
know it's good. Still I wonder would the following happen, as I related
to my family doctor some two ws ago,

About 35-40 years ago, two ICL salesmen from UK find themselves in
France on some business trip to Paris. The younger speaks English with a
fairly distinct Scottish accent, but clear. After a tiring day they head
for a cafe/coffee shop. Sat at the counter as a customer is Georges la
Robespierre, beret jauntily sat on his head, puffing away at a Gauloise.
The Scotsman in his best effort at French orders up two cups of cafe
noir, perhaps au lait or perhaps two glasses of le vin rouge.

Monsieur Georges on hearing the words emanating from the Scotsman's
mouth comments, "HUH ! Franglais !!!!"

----------------------------------------------------------------------------
-------

[I've set follow ups to comp.lang.cobol only]

"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:yxOhf.624473$tl2.405040@pd7tw3no...
> 
>
> Your question is 'almost' there. Yes that is my Factory 'pattern'
> (although I hate the underlying nonsense about the word 'pattern'). No
> not, "Is this the correct approach ?". If I totally ignore Factory,
> which I am able to do - am I missing features in Factory which 'enhance'
> usage, rather than restrict myself solely to instances. Is that any
> clearer.

After reading this post, and Pete's post, I'm fairly confident that what
COBOL calls "FACTORY" has nothing (or, at most, very little) to do with the
"Factory pattern" from the Gang of Four. Instead, it seems to be
representing some sort of concept of "meta-object". That is, the factory
object of object A is the object that created object A.

It's sometimes useful to define methods and properties on the factory
object, because all objects of the same class will have the same factory
object, and so if they wish to share data with each other, factories seem
like the obvious way to do it.

In this context, the factory acts like the "static" keyword in Java (but
there isn't any one to one correspondance between the factory concept and
some concept in Java; rather factory overlaps with several concepts in Java,
including the static keyword and the class Object, but don't fully cover
them either).

Using the "static" keyword is generally frowned upon except as a last
resort. It's just a sort of rule of thumb, like declaring everything with
visibility "public" is also considered a bad practice in Java. One poster in
a Java newsgroup (I forget which one) went so far as to say that you should
never use the static keyword at all, and showed alternate implementations
for every situation that traditionally called for the usage of the keyword.

So in summary, by default, you probably shouldn't use FACTORY. If you
get stuck and the most elegant solution involves using FACTORY, then go
ahead and use it, but don't lose any sleep from "under-using" it.

> No specific project in mind, but the approach is intended for any
> project. As regards UML as one of the whiz kids at Micro Focus wrote
> when I quizzed, just another interesting tool, which  he learned from a
> course. Same goes for Rational Rose
>
> Frankly I am a doer. If I want to do something, I'll think it through in
> my head, establishing my own 'pattern' or using really old terminology,
> a FLOWCHART showing the programs ins and outs. Does the reasoning feel
> right.

Agreed, with some reservations. When I'm trying to come up with a design
for myself, I'll usually use my own notation, because I don't want to get
bogged down in syntactic detail when the ideas are flowing. However, UML is
an effective *communication* tool: Because my diagrams are in my own
notation, no one can be expected to understand what they mean. By converting
my diagram to UML notation, anyone else who knows UML will be able to
understand the design, thus speeding up communication.

> Now can I translate that into code - and by hook or by crook - if my idea
> has merit I'll code to make the language, whichever it is, fit my ideas -
> not become subservient to some preconceived design patterns.

Two things here:

1) If you're fighting the language, you should probably consider writing
the program in a different language (unless the language is some sort of
client requirement, in which case you're SOL).

2) The concept behind design patterns is "learn from the experience of
others". The book "Design Patterns" from the GoF essentially says "Here's a
bunch of problems we've had to solve umpteen times. Each time we tried to
solve these problems, our solution got better and better, because of our
past experiences. Here's the are the solutions which we've found to have
matured enough that we don't expect them to change significantly from here
on."

Each design pattern is accompanied with instructions on its usage, but
these instructions aren't explicit like the instructions for assembling IKEA
furniture; rather, they are much more loose, like instructions in a
parenting book. Occasionally, I'll apply a pattern exactly as like the
example implementation in the book, but very often I'll also apply it with
some variations due to the unique situation or problem that my software has
to solve. The book also sometimes lists possible variants along with their
examples.

> So back to Factory usage it is a 'blind' method if you like. invoke
> ThisClass "new" from the INVOKER class then the INVOKEE class
> understands, even if Factory is not present, that it must 'climb' the
> hierarchy up to class Base which does the initial cookie cutting based
> on the Class you are referencing.

This behaviour of climbinging the tree to look for a method is
traditionally called "method inheritance", and it's a very standard feature
to have in object oriented languages (I don't know of any OO language which
doesn't have it, but it's conceivable that such a language could exist).
 
>
> Base - "The buck stops here". If you make a typo on the name of an
> invoked method, obviously the runtime goes searching, and on failing you
> arrive at Base which will generate a runtime error "Class MyCustomerDialog
> does not understand message OllieWong", when there is only a method for
> 'OliverWong'.
>
> Please remember specifically, I'm talking about Micro Focus support
> classes. Yes, there are sub-roots, and an obvious one, GUI classes for
> the individual controls report to Class Dependent; that in turn reports
> to Base. Dictionaries/Collections, along with some character/array
> classes are in a sub-group also reporting to Base. I haven't used them
> but I also have a subset on Java, which allows for inter-language
> communication. That is in my Version 3.1. If you upgrade to the current
> V4.0 compiler - inter-communicatin with any language using dotNet.

Yes, it sounds like COBOL has a single root object hiearchy (and Pete
confirms it too in his post) in that every object in COBOL eventually (if
you go far enough) extends from Base. Java and C# also have a single root,
but C++ has multiple roots.

> The next is an M/F extension and not part of COBOL 2002 :
>
> "SELFCLASS enables an instance object to send a message to the factory
> object which created it. The method invoked is a method in the factory
> object. If you use SELFCLASS from a factory method, it points to the
> metaclass for this class, which is an instance of Behavior".
>
> Oops ! Behavior. A class which is immediately subordinate to Class Base
> - they more or less work as a pair.

I think this is essentially saying that every object has a class (which
is normal in OO). Classes themselves are objects, so they have classes too
(also normal in OO). The class of every class object is called "Behaviour",
and Behaviour extends Base (everything eventually extends Base, so this
isn't too surprising).

For what it's worth, in Java, the class of every class object is called
"Class". And the class that every class eventually extends (i.e. the root of
the object hiearchy) is called "Object".

>
> I could try and wade my way through the legalese jargon in the Standard,
> but let's see how M/F put it in their on-line manual. Well, having read
> the following before copying/pasting, and I'm not claiming a victory, it
> does appear to give a resounding 'YES you don't need Factory' to my query.
> Do you agree. Or is there somebody out there who would disagree ? I think
> it worth quoting in full :-
>
> -------------------------------------------------------------------------
[snip]
> --------------------------------------------------------------------------
-
>
> I think at this point I could pack it in. Above indicates what I'm doing
> is perfectly acceptable and nothing really in what they say about using
> FACTORY turns me that I should think "I MUST use Factory".

You are correct in understanding that you don't need to use FACTORY if
you don't want to. It's usefulness, as mentioned in the explanation which
I've snipped, lies in that all instances have access to the factory that
created it (via SELFCLASS), and that there exists only one such factory
object for every class. So again, it's mainly useful for sharing or
communicating data among all objects of a given class.

>
> For certain what you mentioned above gets up their noses, and in fact gets
> up mine. It starts with your phrase above, "Where it becomes more useful
> is when you're not sure yet what kind of object you want to create.
> Imagine you have a class hiearchy such that you  have a abstract class
> "Person" and you have a class "Man" which extends etc....".
>
> I recall years ago a COBOLer commenting, having read some text on OO, and
> the example was obviously talking about hierarchical structures with
> reference to animals, he commented "What have giraffes, elephants and
> camels got to do with business programming ?". I sympathized with his
> thoughts. Might be useful if I was a zoo keeper and had to feed the
> animals at Calgary Zoo.
>
> I think you can get positively esoteric and go off into space about
> formulating abstract objects. Still if that's your scene, go for it. I for
> one know exactly which objects I want to create, a COBOL file, an SQL
> Table, a Dialog, EditProgram or PrintProgram etc.

Fair enough. I think the tradition of using examples with no real
business value comes from academia. The concept of not knowing what kind of
object you have is central to "polymorphism", and generally speaking, if
when you start using polymorphism in real production code, you're probably
doing something at least of medium complexity. Since teachers don't want to
actually bog students down with a "real business problem" when the problem
they're trying to address right now is getting students to grasp
polymorphism, the teachers will usually use a much simpler (though
unrealistic) example, such as "Person, Man, Woman" and "Animal, Giraffe,
Lion", etc.

Here's a more "real life" example of using the Factory pattern (lifted
from the GoF book):

Imagine you want to write a program which is supposed to run on multiple
platforms (Windows, Mac, Linux, etc.) and which supports graphical user
interfaces. Because of the latter, it has would probably have classes like
"Button", "Window", "Label", "TextField", etc. Because of the former, these
are all abstract classes, and there would exists "MsWindowsXPButton",
"MsWindows9xButton", "AppleOSXButton", "AppleOS9Button", "LinuxKDEButton",
"LinuxGnomeButton", etc. The reason being that each OS has a very different
interface for using their native GUI widgets, and so the code often has to
be very different. For example, perhaps on Windows, labels and text fields
are completely different things, whereas on Mac, labels are simply text
fields which cannot be edited (I'm just making this up as an example, I have
no idea how labels or textfields are actually implemented on those OSes).

But as a programmer, I don't want to write code like:

Button myButton;
if (System.getOperatingSystem() == "Microsoft Windows") {
if (System.getOperatingSystem().getVersion() == "XP") {
myButton = new MsWindowsXPButton();
} else if (System.getOperatingSystem().getVersion() == "98") {
myButton = new MsWindows9xButton();
} else if (System.getOperatingSystem().getVersion() == "95") {
myButton = new MsWindows9xButton();
} else if (System.getOperatingSystem().getVersion() == "3.1") {
myButton = new MsWindows16BitButton();
}
} else if (System.getOperatingSystem() == "Linux" {
...

And so on every time I want to create a button. Imagine one day
Microsoft decides to release a new operating system called "Windows Vista".
Then every location I've written the above code, I need to add a new if
statement to check the version string against "Vista", and create a new
MsWindowsVistaButton.

Instead, you could create a "WidgetFactory" where you place all that
code once. Outside of that factory, all you know is that you're getting a
"Button". You don't know specifically what kind of Button you're getting,
but in this case, not knowing is actually a good thing: It relieves you some
of the burden of responsibility.

- Oliver