 |
AppletTalk.com
Java discussions newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
James J. Gavan
Guest
|
 Posted: Fri Nov 25, 2005 12:43 am Post subject: OO Factory |
 |
|
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"
|
|
| Back to top |
|
 |
Roedy Green
Guest
|
| Posted: Fri Nov 25, 2005 1:41 am Post subject: Re: OO Factory |
|
|
On Fri, 25 Nov 2005 00:43:01 GMT, "James J. Gavan"
<jgavandeletethis (AT) shaw (DOT) ca> wrote, quoted or indirectly quoted someone
who said :
| Quote: | Your reference to Gang of Four
|
see http://mindprod.com/jgloss/gof.html
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
|
|
| Back to top |
|
|
James J. Gavan
Guest
|
| Posted: Fri Nov 25, 2005 5:38 pm Post subject: Re: OO Factory |
|
|
James J. Gavan wrote:
| Quote: | 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".
|
Java help,
Sincere apologies for posting this here. The 'original' which I
considerably changed, was addressed 'comp.lang.javahelp' and I used that
as the skeleton to post to comp.lang.cobol. I continued the text,
occasionally saved and eventually sent it. Strange, couldn't find it in
comp.lang.cobol ???? Only this morning checking sent messages - there it
is sat addressed to you folks.
So briefly, with his 'dual' background, I'm asking Oliver to respond in
c.l.c.
Jimmy, Calgary AB
|
|
| Back to top |
|
|
Oliver Wong
Guest
|
| Posted: Fri Nov 25, 2005 5:57 pm Post subject: Re: OO Factory |
|
|
Crossposted to comp.lang.cobol 'cause I think it'd be more on-topic there.
"James J. Gavan" <jgavandeletethis (AT) shaw (DOT) ca> wrote
[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.
Are you essentially saying "This is how I've implemented the Factory
pattern in my COBOL program. Is this the correct approach?" ?
| Quote: | 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.
|
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?
In the meantime, I'll try to pick up the "easy" parts of your post and
address them right away.
| Quote: | 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.
|
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.
| Quote: | 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 ?
|
Did you mean to post this on comp.lang.cobol?
| Quote: |
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.
|
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.
| Quote: |
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'
|
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/csis4650/A&D/UML_tutorial/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).
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.
| Quote: | 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.
|
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?
| Quote: |
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.
|
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.
| Quote: | 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.
|
Yes, so far so good.
| Quote: |
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
|
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.
| Quote: |
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 !).
|
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.
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.
| Quote: | This I liked for terminology - you can consider Factory as being used for
a SINGLETON INSTANCE.
|
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.
| Quote: |
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 ?
|
Yeah, I think so. Basically, it sounds like different dialects of OO
COBOL handle finalization differently.
| Quote: |
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.
|
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:
*>AAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
*>------------------------------------------------------------------
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
|
|
| Back to top |
|
|
Oliver Wong
Guest
|
| Posted: Fri Nov 25, 2005 5:58 pm Post subject: Re: OO Factory |
|
|
"James J. Gavan" <jgavandeletethis (AT) shaw (DOT) ca> wrote
| Quote: |
Java help,
Sincere apologies for posting this here. The 'original' which I
considerably changed, was addressed 'comp.lang.javahelp' and I used that
as the skeleton to post to comp.lang.cobol. I continued the text,
occasionally saved and eventually sent it. Strange, couldn't find it in
comp.lang.cobol ???? Only this morning checking sent messages - there it
is sat addressed to you folks.
So briefly, with his 'dual' background, I'm asking Oliver to respond in
c.l.c.
|
Sorry, I didn't see this message until after I had already posted my
reply on c.l.j.h. Oh well, let's just continue the discussion in c.l.c (to
which my reply is also crossposted).
- Oliver
|
|
| Back to top |
|
|
James J. Gavan
Guest
|
| Posted: Sat Nov 26, 2005 1:05 am Post subject: Re: OO Factory(1) |
|
|
Oliver Wong wrote:
| Quote: | Crossposted to comp.lang.cobol 'cause I think it'd be more on-topic there.
"James J. Gavan" <jgavandeletethis (AT) shaw (DOT) ca> wrote in message
news:p6thf.601829$oW2.508954 (AT) pd7tw1no (DOT) ..
OK Oliver,
[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).
| Quote: | 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.
| Quote: |
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.
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.
| Quote: |
In the meantime, I'll try to pick up the "easy" parts of your post and
address them right away.
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.
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.
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 ?
Did you mean to post this on comp.lang.cobol?
MOST DEFINITELY !
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.
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.
| Quote: |
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'
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.
| Quote: |
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/csis4650/A&D/UML_tutorial/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.
| Quote: | 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 |
| Quote: |
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.
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
| Quote: |
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/supportline/documentation/books/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.
| Quote: | ------------------- end Example 3 -----------------------------
As you can see finishes up with exactly the same result as Example 2, but
with the shortcut.
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
| Quote: |
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
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'.
| Quote: |
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 !).
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".
| Quote: |
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.
| Quote: |
This I liked for terminology - you can consider Factory as being used for
a SINGLETON INSTANCE.
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.
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 ?
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.
| Quote: |
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.
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:
*>AAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
*>------------------------------------------------------------------
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.
| Quote: |
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.
| Quote: |
There we go Oliver. I'm primarily using only Instance Objects, that
singleton for ErrorMessages - am I missing out on the subtleties of
FACTORY ?????
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 weeks 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 !!!!"
-----------------------------------------------------------------------------------
|
|
| Back to top |
|
|
Pete Dashwood
Guest
|
| Posted: Sat Nov 26, 2005 1:44 am Post subject: Re: OO Factory |
|
|
"Oliver Wong" <owong (AT) castortech (DOT) com> wrote
| Quote: |
Crossposted to comp.lang.cobol 'cause I think it'd be more on-topic there.
"James J. Gavan" <jgavandeletethis (AT) shaw (DOT) ca> wrote in message
news:p6thf.601829$oW2.508954 (AT) pd7tw1no (DOT) ..
OK Oliver,
[snip]
snipped long discussion with examples |
This is all good stuff, but I simply don't have time to write a paper about
it... (sighs of relief all round).
FACTORY in COBOL is very adequately described in Wil Price's "Elements of
Object Oriented COBOL" Second Edition.
Some quick answers to Oliver's questions...
1. Yes, OO COBOL uses inheritance from a single Base. Beneath that, multiple
inheritance is supported, but rarely used. (For quite a long time I
confused multiple interfaces with multiple inheritance; I know better now...
)
2. FACTORY CAN be used to provide a generic constructor (new) but doesn't
HAVE to be.(As Jimmy realised through experiment, you don't HAVE to have a
FACTORY at all.)
3. Yes, COBOL FACTORY corresponds fairly well with the use of "public
static" in Java.
Fujitsu provide a Class Generator that allows COBOL to use the Java Classes.
In effect the generator creates corresponding COBOL objects when Java
Classes are referenced. You could use this facility to add COBOL control to
a complete Java system (although I can't imagine why you would do that), or
to simply make the full Java Class library available to an OO COBOL program
(that sounds much more sensible to me...)
Notice in the following description of what the "J Adapter" Class generator
can do, how the COBOL FACTORY is used...
Using adapter classes generated by the J adapter class generator enables the
following types of operation for Java:
To COBOL programs, Java objects seem to be COBOL objects. Therefore, Java
objects can be handled the same way as ordinary COBOL objects.
.. Accessing a class variable
Access to a public class variable (static field) declared in a Java class is
enabled.
COBOL handles it as a factory property.
.. Invoking a class method
A public class method (static method) declared in a Java class can be
invoked.
COBOL handles it as a factory method.
.. Generating an instance object (invoking a constructor)
Invoking a constructor can create a Java instance object. COBOL handles it
as a factory method that returns an object reference..
.. Accessing an instance variable
Access to a public instance variable (non-static field) of a Java instance
object is enabled. COBOL handles it as an object property.
.. Invoking an instance method
A public instance method (non-static method) of a Java instance object can
be invoked. COBOL handles it as an object method.
.. Receiving an exception
An exception caused when a class method, constructor, or instance method is
invoked can be trapped to perform error processing. COBOL uses the USE
statement to receive an exception object.
And here are the things that it CANNOT do...
The J adapter class generator cannot perform the following types of
operation:
.. Inheriting a Java class
A COBOL class inheriting a Java class cannot be defined. Even if a COBOL
class inherits an adapter class, the Java class function cannot be
overwritten.
.. Passing a COBOL object as a parameter
No COBOL object can be passed as a parameter for invoking a method, nor can
a COBOL object be set for a Java field. Only an adapter object produced by
wrapping a Java object can be passed to Java.
Therefore, the following restrictions apply to COBOL:
- Listener
Java registers a listener object, in which event processing logic is
written, within an object that generates an event. However, since no COBOL
object can be registered in a Java object, COBOL cannot be used to write
listeners.
- Collection class
No COBOL object can be registered in a Java collection class. When using
COBOL objects as a collection, use a COBOL collection class.
.. Invoking COBOL from Java
No COBOL program can be invoked from Java.
This last simply makes a good case for wrapping the COBOL code as an ActiveX
or COM component and then it CAN be invoked from Java... or anything else.
(Sorry, I sound like a broken record... I simply can't understand why many
people here haven't realised how important this is. Why would you build OO
COBOL and NOT wrap it so it can be used (and reused) anywhere? Components
rule! )
Obviously, using the adapter also facilitates access and manipulation of
beans.
4. The main advantage for a COBOL programmer in using FACTORY is that it's
methods are available to all methods of the Class (common processing can be
inherited and the new class method only needs to extend what is in the
factory), and it can be used to store data that is common to the whole
class, rather than any particular method in the class. (For example, keeping
a count of the number of instances that have been generated, storing common
data that could be used by many of the class methods [the factory would
contain GET and PUT methods to provide it; encapsulation prevents any class
method accessing the data directly], and also to store references and
states. It can therefore provide a "staging post" for methods that are not
stateless and need to recognise some previous event, either at the time an
instance of their object is constructed, or later, when they are simply
invoked on an existing instance. In fact, the factory can store object
references to already created instances and provide them if required.
FACTORY is useful.
This is an excellent "revision" and "consolidation" tutorial for those of us
who use UML. I'll be passing it on to my team and went through it myself and
remembered a few things I had almost forgotten.
Thanks very much for this, Oliver.
| Quote: | 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).
|
I hope the above has clarified this.
| Quote: |
It sounds like what COBOL calls "Factory", Java calls "static", and UML
calls "class scope" (as opposed to "instance scope").
|
I'd agree with that; it is close enough to continue the discussion. The
FACTORY in COBOL certainly applies at Class level.
| Quote: | 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?)
|
Well, I've done my best in the short time I have available for this. It is a
good discussion and I wish I could get more involved. I simply can't right
now. Maybe later.
Pete.
|
|
| Back to top |
|
|
Chuck Stevens
Guest
|
| Posted: Mon Nov 28, 2005 4:31 pm Post subject: Re: OO Factory |
|
|
"Oliver Wong" <owong (AT) castortech (DOT) com> wrote
| Quote: | 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
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
