Home > Archive > Cobol > April 2005 > Please Explain about FACTORY
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Please Explain about FACTORY
|
|
| apknight 2005-04-25, 3:55 pm |
| Please Explain about FACTORY and Some Example .....
| |
| Pete Dashwood 2005-04-25, 3:55 pm |
|
"apknight" <apknight@gmail.com> wrote in message
news:95895e6d.0504250408.5c744cb8@posting.google.com...
> Please Explain about FACTORY and Some Example .....
>
It's a place where you make things.
In Object Oriented COBOL it contains storage and methods that can be used to
generate objects of the class. The factory is separate from Object instances
and they cannot access its storage, nor vice-versa. It is a bit like the
part of the Class that would do initialisations, handle common environment
processes, and create new instances (handles/object references) when
requested by applications.
You would need to specify which compiler you are using and possibly explain
why you haven't read the documentation and examples supplied by your vendor,
before I would spend time on responding to this.
My experience has been that few people here are interested in OO COBOL, even
fewer really understand it, despite many explanatory posts with examples
and simple explanations, this hasn't really changed in the last 6 years or
so. Many people here don't have access to an OO COBOL compiler, many of them
work on sites where it would not be allowed even if they did, so it is
understandable.
In my opinion, OO COBOL simply missed the boat. Too late and too
complex/verbose. (Having said that, I have used it to build components
(ActiveX and COM, mainly) for many years now and find Fujitsu excellent for
this.)
Pete.
| |
| Lueko Willms 2005-04-25, 3:55 pm |
| .. On 25.04.05
wrote apknight@gmail.com (apknight)
on /COMP/LANG/COBOL
in 95895e6d.0504250408.5c744cb8@posting.google.com
about Please Explain about FACTORY
a> Please Explain about FACTORY and Some Example .....
Have you read the chapter E.17 "Object Oriented Concepts" in the
2002 Standard? That gives quite a good introduction to the COBOL OO
concepts.
The standard can be downloaded for 18 USD from NIST, or how that is
called today.
Yours,
Lüko Willms http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --
Er trieb einen kleinen Finsternis-Handel. -G.C.Lichtenberg
| |
| James J. Gavan 2005-04-25, 3:55 pm |
| apknight wrote:
> Please Explain about FACTORY and Some Example .....
If my memory serves me well, aren't you the S. Korean who is looking at
COBOL *without* a compiler ? As Bill Klein pointed out with regard to
Micro Focus DIRECTIVES, it really is a waste of time without a compiler
to use and show you what is happening.
Somebody referred you to the COBOL Standard to look at - a bit of a
'toughie' I would suggest, although one of the chapters/appendices does
have some OO code examples.
As already indicated a FACTORY is a means of using a 'cookie-cutter' to
produce as many instances as you want of a particular class. However if
you do want to pursue the topic, go to the Micro Focus on-line book
which is about OO :-
http://supportline.microfocus.com/s...40/nx40indx.htm
Pick up on the last line under 'Programming' for the OO book.
Jimmy, Calgary AB
| |
| William M. Klein 2005-04-25, 8:55 pm |
| IBM's OO implementation does NOT match the ANSI/ISO 2002 Standard, but to answer
this specific question, you might want to look at:
http://publibz.boulder.ibm.com/cgi-.../igy3pg20/6.1.6
(Remember that IBM uses a Java-influenced and interacting OO solution for
COBOL.)
The entire section beginning at:
http://publibz.boulder.ibm.com/cgi-...KS/igy3pg20/6.1
gives a pretty good "introduction" to their approach.
***
For information on the Micro Focus implementation (close - if not quite
identical - I'm not sure) to the ISO 2002 definition, go to:
http://supportline.microfocus.com//...nx40/oppubb.htm
and look at the book:
"Object-oriented Programming with COBOL"
There is even a section under that (use the index or the table of contents)
called
"Programming Factory Object Behavior"
--
Bill Klein
wmklein <at> ix.netcom.com
"apknight" <apknight@gmail.com> wrote in message
news:95895e6d.0504250408.5c744cb8@posting.google.com...
> Please Explain about FACTORY and Some Example .....
| |
| James J. Gavan 2005-04-25, 8:55 pm |
| William M. Klein wrote:
> IBM's OO implementation does NOT match the ANSI/ISO 2002 Standard, but to answer
> this specific question, you might want to look at:
>
> http://publibz.boulder.ibm.com/cgi-.../igy3pg20/6.1.6
>
> (Remember that IBM uses a Java-influenced and interacting OO solution for
> COBOL.)
>
> The entire section beginning at:
>
> http://publibz.boulder.ibm.com/cgi-...KS/igy3pg20/6.1
>
> gives a pretty good "introduction" to their approach.
>
> ***
>
> For information on the Micro Focus implementation (close - if not quite
> identical - I'm not sure) to the ISO 2002 definition, go to:
>
> http://supportline.microfocus.com//...nx40/oppubb.htm
>
> and look at the book:
>
> "Object-oriented Programming with COBOL"
Bill,
Just so you don't have to keep qualifying yourself with "I'm not sure".
You can be SURE at this point in time, right up to N/E 4. There are
possibly some other features which I'm not using - BUT - the following
were "extensions" PRIOR to COBOL 2002 and are still in the happy state
of being "extensions" after COBOL 2002.
Class-id. MySuperClass data is protected.
Class-id. MySubClass inherits from MySuperClass with data.
The effect of the above, compile # 1 FIRST which generates 'inclusive'
files INS and CLS.
Now compile # 2 and it picks up on those "inclusive" files
The FACTORY for #2 can have an empty OBJECT-STORAGE SECTION - but it
wont compile without that OBJECT-STORAGE SECTION syntax which is used to
pick up on the 'inclusive' file info. In MySubClass you can make direct
reference to objects in #1 without having to word :-
invoke super "getThisObject" returning .....
Note : The syntax for the above is probably better illustrated in the
LRM Chapter 17 which starts off with the MF "balloon" - i.e., these are
extensions.
Jimmy
>
> There is even a section under that (use the index or the table of contents)
> called
>
> "Programming Factory Object Behavior"
>
| |
| Lueko Willms 2005-04-25, 8:55 pm |
| .. On 26.04.05
wrote dashwood@enternet.co.nz (Pete Dashwood)
on /COMP/LANG/COBOL
in 3d4cvoF6re3v6U1@individual.net
about Re: Please Explain about FACTORY
PD> It's a place where you make things.
PD>
PD> In Object Oriented COBOL it contains storage and methods that can be
PD> used to generate objects of the class.
Is that what in other languages is called the constructor or
desctructor?
Yours,
Lüko Willms http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --
Seine Bücher waren alle sehr nett, sie hatten auch sonst wenig zu tun. -G.C.Lichtenberg
| |
| James J. Gavan 2005-04-26, 3:55 am |
| Lueko Willms wrote:
>
> Is that what in other languages is called the constructor or
> desctructor?
>
Constructor - YES
More than one way to do this :-
You have a template class which may contain all you need to create
Dialogs - for each you pass a set of parameters/properties. So :-
perform varying n from 1 by 1 until n > 5
invoke MyMasterDialog "new"
using os-DeskTopParent returning os-MyDialog (n)
*> might need the Desktop for messaging
invoke os-MyDialog (n) "begin" using ws-DialogParameters (n)
*> this is the "guts" of what you want to display
End-perform
So you now have a table :-
01 MyDialogs.
05 os-MyDialog occurs 5 object reference.
So you can chop and change between each "instance" putting a value in 'n'
invoke os-Dialog (n) "doThis" using .....
Note it's the parameters/properties above that makes each of the
'instances' visually different.
Destructor - NO ! (That's only Arnie in the 'Terminator')
That's auto garbage collection - go look at the other J4 TR -
"Finalizer". Not sure, but at the moment Fujitsu have, I believe, some
built-in auto garbage collection. Net Express doesn't - we have to use
methods "finalize" to destroy objects.
Before I forget - I have asked but as yet haven't seen justification for
actually coding "FACTORY". Even though the class may only contain OBJECT
syntax (an empty FACTORY, or not even coded), invoking a class "new"
automatically goes to the appropriate compiler's "Base", (top of the
class hierarchy), to trigger "new".
Jimmy
| |
| Michael Wojcik 2005-04-26, 3:55 pm |
|
In article <bdfbe.1134798$8l.491135@pd7tw1no>, "James J. Gavan" <jgavandeletethis@shaw.ca> writes:
> Lueko Willms wrote:
> Constructor - YES
Though languages with constructors can also have factories.
Factories are quite common in more complex Java APIs, such as JAX,
for example. They have certain advantages over constructors (like
polymorphism).
There was an article in DDJ a few years back on what's wrong with
Java's "new" and why factories are better in some cases.[1] You
need to be a registered user to read the whole thing.
1. http://www.ddj.com/documents/s=7027/ddj0204a/0204a.htm
--
Michael Wojcik michael.wojcik@microfocus.com
I would never understand our engineer. But is there anything in this world
that *isn't* made out of words? -- Tawada Yoko (trans. Margaret Mitsutani)
| |
| Pete Dashwood 2005-04-26, 3:55 pm |
|
"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9VZ$-BE9flB@jpberlin-l.willms.jpberlin.de...
> . On 26.04.05
> wrote dashwood@enternet.co.nz (Pete Dashwood)
> on /COMP/LANG/COBOL
> in 3d4cvoF6re3v6U1@individual.net
> about Re: Please Explain about FACTORY
>
>
> PD> It's a place where you make things.
> PD>
> PD> In Object Oriented COBOL it contains storage and methods that can be
> PD> used to generate objects of the class.
>
> Is that what in other languages is called the constructor or
> desctructor?
>
Yes. In other languages it is a constructor. (ususally it implements the
'NEW' method of the class. You don't need a factory for this, as this method
can be inherited from the class base, but putting it in the factory makes it
explicit, and the factory can combine references to other obect methods that
cannot be achieved by inheritance alone. For example, the factory could
store internally a number of references to related objects for a specific
instance of a specific object it was being asked to create. When the
specific object was instantiated, the factory would 'gather' the object
references of the related objects as part of an 'initialisation' or
'startup' for the new obect. These object references can be stored in the
factory's local storage. The reference returned for the new object can then
be used to access the related objects, via the factory.
This is just one use of the factory. (Most OO languages provide a similar
facility, not just COBOL...)
The factory does not normally deal with destruction (although it certainly
can), as this is achieved by nulling the object reference. (Some less OO
systems require the specific invocation of a garbage collection object or
method. I believe VB, Java, and Fujitsu COBOL, garbage collect
automatically when pointers are nulled.) Stateless systems like JavaScript
don't even need the pointer to be nulled, although it can be...
Often, the factory is useful where there is a hierarchy of objects, as it
can automatically 'fill in the blanks' when a new object at a new level is
instantiated.
HTH,
Pete.
| |
| James J. Gavan 2005-04-26, 3:55 pm |
| Michael Wojcik wrote:
> In article <bdfbe.1134798$8l.491135@pd7tw1no>, "James J. Gavan" <jgavandeletethis@shaw.ca> writes:
>
>
>
> Though languages with constructors can also have factories.
> Factories are quite common in more complex Java APIs, such as JAX,
> for example. They have certain advantages over constructors (like
> polymorphism).
>
> There was an article in DDJ a few years back on what's wrong with
> Java's "new" and why factories are better in some cases.[1] You
> need to be a registered user to read the whole thing.
>
>
> 1. http://www.ddj.com/documents/s=7027/ddj0204a/0204a.htm
>
Michael,
As I said I tried to get a handle on FACTORY usage. Firstly I always
hard-coded a FACTORY method "new" - based on the format I picked up from
Arranga/Coyle, (book was '96/'97, using M/F for examples); each of their
*own* invoked classes had this format.
Not sure of sequencing, i.e. (1) or (2) but -
(1) Read in Net Express V 4 on-line OO Manual that you don't need a
FACTORY to create a "new". Well I'll be blowed ! So wrote to Donald,
Will Price and some others using N/E. Back comes Donald (using Fujitsu),
"Never used Factory". Will Price, "Look at my Second Edition of my OO
Book - you don't need a hard-coded FACTORY". Whoops ! I missed that one.
(2) Out of curiosity one time went looking at comp.lang.objects - under
the impression 'FACTORY' was unique to COBOL. Not so, as you write
above. There I see a reference to FACTORY. So I queried - funny we are
supposed to learn to *understand* other languages - they hadn't a bloody
clue what I was talking about when I *tried* to illustrate with COBOL.
Even though Karl Kistler (Fujitsu-Siemens), who keeps a 'watching
brief', jumped in to explain what I was asking - still no takers. All I
got was some reference to an article somebody had written on FACTORY in
general terms.
I don't dismiss FACTORY - I just want to see a case, (rather - an actual
example), where it is an 'advantage'.
As an example - just finished doing a Treeview to test all possibilities
in the N/E GUI classes TreeviewControl and TreeviewItem, before I use it
against a *real* application. Usual trigger program to start OO in COBOL
which invokes AppDriver "new". This in turn invokes AppHousekeeping
"new" to do 'housekeeping' (a) establish handles to files (will be DB
Tables when I go *real*), (b) does the first run to create the initial
Treeview. Having done its work - AppHouse passes back the file and Tree
objects to AppDriver. AppHouse is now irrelevant so I can "finalize".
The objects within AppDriver are stored in the OBJECT - not FACTORY. The
Driver displays current Treeview; on a user selection show a Pop-Up menu
then invoke the appropriate DBI(Database Interface) using the Treeview
LevelNumber - e.g. invoke os-Dbi(ws-LevelNumber) "addRecord" or
"changeRecord" using TvCurrentObject. The appropriate DBI also invokes
the appropriate File/DB Table.
No - I still don't write off usage of FACTORY - but as yet haven't
found any validity for using it.
Jimmy
|
|
|
|
|