| James J. Gavan 2005-11-25, 9:57 pm |
| 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 (perhaps
> 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 gist
> 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?
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 anything
> 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 got
> 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 the
> 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 fields
> 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 :-
http://supportline.microfocus.com/s...nx40/oppubb.htm
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 COBOL
> 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 instance
> 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 what
> 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.
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 UML
> 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 written:
>
> *> 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 you
> were already doing anyway (since it seems to me that Java statics = OO COBOL
> 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 w s 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 !!!!"
-----------------------------------------------------------------------------------
|