RE: IBM pushing Java

But what happens when you have developed a large application over many
years, and you have thousands of these "objects". 

Is a new developer going to wade through the documentation for these
maybe complex objects, or is he just going to create a new one , because
he thinks his object is better that fred's. 

Then over a period of time would you end up with lots of different
objects that do the same thing!!!

So now we don't bother to re-use the objects apart from the core ones,
we just create new ones each time, and it just becomes the sames mess
that we have now.

Has any large scale application been developed in JAVA, to test this
theory!!!

                -----Original Message-----
                From:   James W Kilgore
[mailto:email@james-w-kilgore.com]
                Sent:   Monday, March 22, 1999 3:41 AM
                To:     MIDRANGE-L@midrange.com
                Subject:        Re: IBM pushing Java

                Booth,

                I'm going to go out on a limb here and display my own
position in the
                learning curve.
                About a year ago I picked up about 50lbs of Java books
and here is what
                I've gotten out of it:

                (Now my terminology will probably not be correct, but I
have to
                translate into lay terms so I can understand it)

                One could define a "name and address" object, which
would include all
                rules of validation.  It does not contain data.  It is
empty.

                To use this object, one would create an "instance".  The
instance
                (usage) does contain data.
                So in defining a "Customer" object, it can contain a
"name and address"
                object.  Even the "Customer" object is empty.  The
instance or maybe a
                better word may be the occurrence (This.customer) does
contain the data.

                From a design point of view, the "name and address"
object would not be
                capable of producing labels.  A label writing object
would be able to
                accept, as input, a "name and address" portion of
objects customer,
                vendor, employee, subscriber, etc.

                In analogy may be: The DDS for a physical file does not
contain any
                data.  In RPG we process an occurrence of the physical
file (a record).

                In real life, the "name and address" object would be a
composite of a
                "name" object coupled to an "address" object.  Therefore
you would only
                define the rules for a name once.  Well actually, you
would have people
                names and company names which would have a totally
different set of
                rules.  Companies don't have first, middle, last names.
OOps, that
                makes "name" three different objects! =:-o

                James W. Kilgore
                email@James-W-Kilgore.com


                boothm@ibm.net wrote:
                > 
                > This seems to be the whole guts, right there.  In the
end, we need to be doing OO stuff.
                > 
                > OO is mentioned through the months, and every cycle of
discussions adds to my decidedly low level of OO comprehension.
                > 
                > Hopefully this cycle will add, too.  To help me
understand the idea of OO:  Lets talk about a particular data object,
the "name and address" object.
                > 
                <<snip>>
                +---
                | This is the Midrange System Mailing List!
                | To submit a new message, send your mail to
MIDRANGE-L@midrange.com.
                | To subscribe to this list send email to
MIDRANGE-L-SUB@midrange.com.
                | To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
                | Questions should be directed to the list
owner/operator: david@midrange.com
                +---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---