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

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

I'll post some of my IDL when I get back home.

> >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.  Smalltalk's hay-day seems
to have immediately preceeded my introduction in OO.

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

> >Is there a cannonical 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 stroing 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.  

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

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

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.