[KLUG Programming] Proper OO Technique Question

[Adam Tauno Williams]

>>So heirs are documented in their parent?
>Generally not. However, what I like to do is simply add a comment to
>one of the parents' source files stating that it is a parent, and of 
>what. The converse is usually coded in, so it's not needed.

Good idea,  somehow that never occured to me.

> >> Home yet? :)
> >Will post when I have something de-moronized.  Shouldn't be long.
> Typical of the OO process. This is often hard to do well, or right.

Actually, a couple kind souls have wacked me upside the head again.  Since this 
is really on the bleeding edge of my capabilities I'm learning (and reading) 
alot.

Apparently a great deal of what I want to do it already done, I just need to 
learn how to adapt it to my solution (CORBA/IIOP).  Much of which involves 
linking methods, etc... areas I've never delved into much.

Altogether very fascinating however.

>>>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-oriented
>>>(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 steer the sinking-ship-called-reality as near that point as the
>>implementation allows.
>The original notions ran along the lines of starting up the run-time
>environment and then invoking a constructor that would materialize an
>object which would do all kinds of initialization and then go into a 
>wait state (and perhaps listen on some I/O channel) until something 
>happened that disturbed this. Many environments required that this
>or a similar machinery be visible, others not. Some systems simply start
>up by indicating what objects are constructed on startup, and each 
>object registers itself into the environment by asserting what events
>it will handle, and then everything goes into a wait state.

Pleasently (I think:) it appears the Skyrix/oGo/GNOME/ORBit people have a huge 
amount of that machinery in place.  It is really an issue of figuring out which 
of the myriad levers I have to pull.

>The event-driven model seems to be very attractive in OO, since it does
>not demand that any procedure sit on top of this bunch of objects, which
>are supposed to do all the work anyway.

It does seem to result in code that does a great deal more with a lot less.

>>On inspection I think I really start from "OgoAccount" based upon the
>>sign in criteria,...
>Seems like you're taking a rather different approach this time round, which 

Yes, I wasn't even aware of oGoAccount before, or of the DocAPI, or of.... the 
list goes on.

>is almost always quite helpful. When [if] you throw out this version, don't
>be worried if other views make more sense, and the best solution may be to
>adopt elements for each design effort and see how they can be combined.
>> ....
>>>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.
>This is common, the rules does NOT say "throw ONLY the first version away",
>it may take 2 or 3 tries, I've seen as many as 5 before something really
>solid emerged; but then again we were designing something with about 800
>classes, with lots of other stuff similarly scaled....

>From how this is looking; I'll call the City Waste Management Officer and have 
a dumpster dropped of at my house.