[KLUG Programming] Proper OO Technique Question

[Robert G. Brown]

On 11 Aug 2003 08:53:36 -0400, Adam Williams <adam@morrison-ind.com> wrote:
....
>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.

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

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

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.

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

							Regards,
							---> RGB <---