[KLUG Programming] Proper OO Technique Question

[Robert G. Brown]

On 08 Aug 2003 11:39:49 -0400, Adam Williams <adam@morrison-ind.com>wrote:

>>>I've designed a new little project for myself...
>>>Anywho... (it takes me awhile to get to the actual question)
>>I see! :)
>>.... a few details elided for brevity ...
>>>So I've got objects like oGoProject, oGoContact, oGoEnterprise, etc...
>>And they all inherit from a common ancestor?
>Yes.  That always seems a safe thing to do.  But the common ancestor
>doesn't do anything - at this point.  There really isn't much common
>properties/functionality between Project, Contact, and Enterprise.
This often a point of confusion; the base class often doesn't need to 
do much, and is best used in declaration formalities and ought to contain
liberal amounts of commentary regarding its heirs.

>FYI: Enterprises can "contain" contacts,  a contact can be contained by
>more that one enterprise, a project can be associated with multiple
>enterprises and multiple contacts (then referred to as executants, must
>be a German thing).
Perhaps a Smalltalk thing (there IS a difference! :) ).

>From a C/C++ perspective, this is all done with pointers, or to a number of 
pointers....
class Enterprise {
...
Contacts **bunchAContacts;
...
}

A project can "contain" multiple jobs, a job can
>belong to one-and-only-one project, or no project (stand alone task). 
>There is some other stuff with documents but I'm starting small.
That's cool...other declarations flow from each statement, natch.

>I'll post some of my IDL when I get back home.
Home yet? :)

>>>But one question I've always had is what is the proper OO way to enumerate 
>>>the available projects, contacts, etc...
>>>Do you create a oGoProjectList object?  Thats what I've always done in the 
>>>past, but it seems kind of lame.
>>This is one place where a lot of OO models start to err, IM (and some 
>>others)O. This also touches on almost a religious point; some would require
>>you to build a really "grounded" system (like Smalltalk), but I suspect we 
>>don't care a lot for this kind of thing here.
>I don't know anything about SmallTalk, sorry.
No Apology needed, actually. 

>Smalltalk's hay-day seems to have immediately preceeded my introduction in OO.
That's OK. In some sense, you may not have missed a lot. Smalltalk is consi-
dered to be the first truly OO language (not hybrid, or OO-supporting language,
oh many readers).

One thing that has bothered Smalltalk is this notion of "grounded" or "rooted"
class inheritance. They want EVERYTHING to be based on a class inheritance 
scheme that goes back to a single root. Formally elegant, but not nessesarily
useful. IMHO the use of the language has suffered for this.

>>I believe that classes define data types, and objects are instances of a 
>>state (or value) of that data type. As such, you're looking at well-defined,
>>single (or indivisible) values. It is useful to speak of ARRAYS of objects,
>>but mixing the notion of data type and various array properties (such as 
>>the length and shape of an array, among others) harms clarity.
>>Hmmm.  I'm not sure ORBit/IIOP does arrays of IORs - interesting - time
>to check the documentation.
Ya think? :)

>>>Is there a canonical solution to where you "start" in an OO model?
>>I'm not familiar with the OO environment you're wroking in, so I don't know
>>how strong concepts like polymorphism or genericity are developed. Can you
>>(or why not?) simply use arrays of 0Go... objects, perhaps declaring them
>>(if you have to) as some base class... this is a C++'ish/Smalltalk kind of
>>response; these are languages that in esssence force homogenous arrays...
>I'll check out the array thing.  

Yes, its worthwhile to do so, and how do they handle pointers, and/or indexing
and so on.....

After some additional thinking, I'm starting to realize that the answer to
your question is probably too dependent on the details of the particular 
language or implementation that you're using...C++ may be object-oiented
(it's not, it's really object-supporting), but main() is still [usually]
starts things going, and things like wait states and event handling gets 
dealt with by libraries, not in the base language....

>>Perhaps it would help to tell us more about the nature of this environment, 
>>as in how well-developed are some OO characteristics [??]
>It is a little weird.  Almost all GNOME apps are written in C, so are
>not "fundamentalist" OO.  But they use an OO model.  CORBA is OO, but
>you can use any language on the server side that has ORBit bindings. 
>I'm just going with C since that is what the oGoEvo & XimianEvo people
>use and I want to be able to easily steal code. 
All fine... really the object model is what we're talking about here,
independent of language... we can talk about coding after that's covered.

>When I post the IDL (which looks ALOT like C++) it will probably be
>clearer.
OK....

>In my initial little trial all the objects requested by the client
>actually become running processes - far from optimal, but I've written
>that before so I start there.
That's fine, start with what you know, then improve on it, or as I've 
also heard it said: "If you can't write good code, write bad code!"

Of course, this is balanced by another saying: "Always be prepared to
throw the first version away."

							Regards,
							---> RGB <---