Cobol - Re: OO Factory

Author

Re: OO Factory

Oliver Wong

2005-11-25, 6:55 pm

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...
> 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.

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

> Most importantly - COBOL 2002 does have FACTORY - so I'm not on a cru

e
> 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.

> 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?

>
> 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.

>
> 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...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).

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.

> 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?

>
> 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.

> 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.

>
> 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.

>
> 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.

> 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.

>
> 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:

*> 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

Pete Dashwood

2005-11-26, 3:55 am

"Oliver Wong" <owong@castortech.com> wrote in message
news:0gIhf.132167$S4.60745@edtnps84...
>
> 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]
>
<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

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.

>
> 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
>

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.

> 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.

>
> 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.

> 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.

Chuck Stevens

2005-11-28, 6:55 pm

"Oliver Wong" <owong@castortech.com> wrote in message
news:0gIhf.132167$S4.60745@edtnps84...

> 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

James J. Gavan

2005-11-28, 6:55 pm

Chuck Stevens wrote:
> "Oliver Wong" <owong@castortech.com> wrote in message
> news:0gIhf.132167$S4.60745@edtnps84...
>
>
>
>
> Strictly speaking, ISO/IEC 1989:2002 syntax allows the FACTORY paragraph
> (alongside the CLASS-ID, FUNCTION-ID, INTERFACE-ID, METHOD-ID, OBJECT,
> OPTIONS and PROGRAM-ID paragraphs) in the IDENTIFICATION DIVISION. The only
> clause in the standard for the FACTORY paragraph is the IMPLEMENTS clause,
> and it specifies the names of the interfaces that are implemented by the
> factory object of the containing class.
>
> -Chuck Stevens
>
Not being snarky Chuck, but above left me in mid-air. I can't confirm
that following is 100% conforming to J4 Standard, but for Oliver's
info., here is what the N/E 4.0 on-line manual illustrates :-

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

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

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

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

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

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

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

end interface Drivable.

Interface Implementation

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

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

class-id. Car inherits from Vehicle.

configuration section.
repository.
class Car
class Vehicle
interface Drivable

Oliver Wong

2005-11-28, 9:55 pm

"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:dYHif.636350$oW2.188085@pd7tw1no...
>
> Not being snarky Chuck, but above left me in mid-air. I can't confirm that
> following is 100% conforming to J4 Standard, but for Oliver's info., here
> is what the N/E 4.0 on-line manual illustrates :-
>
> *>------------------------------------------------------------------------
> Interface Source Elements
>
> You write your interface definitions in interface source elements. An
> interface source element can contain one or more interface definitions.
>
> The code block below shows the outline of an example interface source
> element. An ellipsis (...) shows where code has been omitted, and
> indentation indicates the levels of nesting. In this example the interface
> Drivable, containing a method prototype for calculating mileage, inherits
> from the interface Rentable, which can be assumed to contain methods
> applicable to all objects that can be rented.

What N/E 4.0 calls "Interface", Java calls "abstract class". Java also
has something called "interface", which is somewhat like N/E 4.0's
"Interface", except that in Java, interfaces cannot have any code for their
methods. They can declare the names of methods, and what parameters are
expected to get passed in and out (like the "USING" and "RETURNING"
clauses), but absolutely no code.

[snip]

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

In Java, (Java-)interfaces, abstract classes and "normal" classes can
all be parametrized this way, so the term used is "parametrized type", but
it sounds like it's exactly the same concept. Parametrized types was
introduced in Java 1.5, which came out about 1 year ago, so you won't find
references to it in older books, and sometimes you'll see posters on the
comp.lang.java.* groups who are unaware of it.

Some people (myself included) feel that the concept of parametrized
types itself is good, but that the way Sun put it into Java was rather poor.
In Sun's defense, the poor implementation had a lot to do with keeping Java
1.5 backwards compatible with previous versions, but as a result of this,
we've lost a lot of the power inherent in the idea.

[snip]

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

Yes, when Java 1.5 was released, parts of the Sun's standard class
library was rewritten to take advantage of parametrized types. The biggest
success story in this rewrite was the API for collections. Previous in Java,
you had Lists into which you could put things, and take them out, but you
had no real way of enforcing that only certain types of things could be put
into any given list. So you might, for example, in one part of the code, put
an object of type A, and then elsewhere, mistakenly assume your list
contained only objects of type B, and tried to extract such an object, which
would cause an error not at compile time, but at runtime, and only when the
actual extraction tried to take place.

With the new syntax added, instead of just having "List", you would have
"List<A>" which meant that the list could only contain objects of type A,
and this could be checked at compile time, thus making it easier to catch
such bugs.

We actually switched from using Java 1.4 to Java 1.5 at my workplace
while I was working there, and we actually discovered a bug like this during
the switch. We had a List called "users", which was obviously a list of
users. Unfortunately, in one location, rather than actually placing objects
of type User into the list, numbers were being placed in the list, these
numbers being the user-id of the user.

It just so happened that that portion of the code was being run so
rarely (never) that we never noticed the bug until we switched to Java 1.5

- Oliver

James J. Gavan

2005-11-28, 9:55 pm

Oliver Wong wrote:
>
> What N/E 4.0 calls "Interface", Java calls "abstract class". Java also
> has something called "interface", which is somewhat like N/E 4.0's
> "Interface", except that in Java, interfaces cannot have any code for their
> methods. They can declare the names of methods, and what parameters are
> expected to get passed in and out (like the "USING" and "RETURNING"
> clauses), but absolutely no code.
>
> [snip]

<snip> from me too - just using above as a reference. I found your input
and observations from the other message fascinating - I'm sure Pete
did too.

I'll get back later with comments - but *really* do have to do something
else at the moment. BINGO ! I'm with you 100% where you were
illustrating getting at different GUIs dependent upon which O/S you are
referencing.

More later.

Nearly missed it - I've never asked before. Can Pete or Donald confirm
whether Fujitsu supply you with the source programs for classes that are
your support utilities, e.g. backup to their collection structure or the
'GUIs' in POWERFORM, (if that's the correct name) ? I think Donald
should clearly understand my question as he has used N/E V 3.0.

Jimmy

Sponsored Links