[KLUG Programming] Proper OO Technique Question

[Adam Williams]

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

So heirs are documented in their parent?

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

I realized I really brain-farted and am re-drafting.  Will post when I
have something de-moronized.  Shouldn't be long.

> >>>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 
{...talk of Smalltalk elided...}

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

Yep, I do, on occasion.

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

Right, but I was curious what the "right" way to do it was.  And then
I'd stear the sinking-ship-called-reality as near that point as the
implementation allows.

On inspection I think I really start from "OgoAccount" based upon the
sign in criteria,  and should be able to walk out to the others from
there.  Hopefully passing back arrays of objects (or object
references);  still grousing through my four CORBA books.

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

Right.

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

Should be forthcoming.

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

Ha!  I've already done that.  Probably will throw the second and third
version away too.