Warp wrote:
>   Yeah, that kind of OO programming has always been considered bad design.

Actually, in this case, it kind of makes sense. You want to call draw() on 
things with a draw() function, call initialize() on things with an 
initialize() function, etc.  Basic duck typing.

>   If C# offered multiple inheritance (I don't know if it does), 

Only via interfaces. Much like Java in that respect.

> then you
> could inherit all the objects you are using from GameComponent and your
> own "base class", which is what the container then contains.

Then everything would be of type GameComponent, and that wouldn't really fix 
that I wanted to use both GameComponents and my own stuff. :-)

In other words, I wanted a generic list that would hold both GameComponents 
that other people wrote that I don't have the source to, as well as my own 
components that have the same routines but a different base class.

>   (Of course this solution wouldn't help if you have to store objects
> which have been eg. instantiated by the library framework itself because
> those would not have been inherited from your "base class".)

Oh. Yes, right, that's the problem.  Other people are writing those 
components. That's what makes them "components."  :-)

Altho I found another sample project that the documentation makes it look 
like it's using the same framework I want to use (same class names, layouts, 
etc), as well as talking about using custom GameComponents as part of it, so 
I need to take time to dig into that source and see if they changed the 
framework to invoke the right routines of a GameComponent as needed.

-- 
Darren New, San Diego CA, USA (PST)
   Yes, we're traveling together,
   but to different destinations.

Post a reply to this message