Need help with OO design problem

[Soulshift]

Hi all,

Here's my problem. I have a design where the class Container inherits
class Widget, and is used to contain and handle the proper display of
widgets and behaves like a widget itself. I have a class IsoWidget
which inherits from class Widget which is used to display isometric
widgets. I want to make a class IsoContainer (which contains
IsoWidgets and behaves like an IsoWidget), and since an IsoContainer
seems like it should inherit from both IsoWidget and Container, I'm
not sure what's best.

I see a few options as of now:
- Use multiple inheritance (ick) to resolve the issue by having
IsoContainer inherit from Container and IsoWidget.
- Copy code from IsoWidget and dump it into IsoContainer (ick)
- Copy code from Container and dump it into IsoContainer (worse)
- Redesign the entire class hierarchy, breaking nearly everything
else, but resulting in a better design.

Does anyone see a better solution? Help!

Thanks in advance,
Soulshift

 

[David White]

Another idea:

template<class Item> class Composite : public Item
{
public:
void add(Item *);
// etc.
};

With this you can have a composite anything.

DW

 

[Agent Mulder]

PS> I'm sort of confused here. So, the class Container inherits from the
PS> class Widget, and is also used to contain instances of Widget?

This concept is (was) common in java 1.1.3, the good old AWT.
There you have a Component that is much like a Widget. Then
java.awt.Container inherits Component AND has the ability to store
Components. I guess it's like inheriting from Box to make a Closet.
You pack your Closet full of Boxes, while your Closet itself IS a Box.

-X

 

[David White]

And just
what you are doing inheriting containers from the things they
contain I can't imagine.

It does make sense in some cases, and is a very powerful technique.
For example, an XyGraph object consists of many smaller objects -
axes, traces, labels etc. It makes things easier if each of those
smaller objects is derived from the same base class, say,
DrawableObject. Since the entire XyGraph object is also a thing that
is drawn, it makes sense if it is also derived from DrawableObject.
The XyGraph's Draw member would in turn call the Draw member of each
of its component objects. Also, the trace objects, for example, might
be made up of many line objects, each of which is also a
DrawableObject. Generalized, this technique enables you to build up a
DrawableObject of any complexity and depth, with both most complex
objects and the simplest of their components having the same base
class and interface.

DW

P.S. I've had to join Google temporarily, because my ISP's newsreader
is down.

 

[j]

I'm sort of confused here. So, the class Container inherits from the

class Widget, and is also used to contain instances of Widget?
So you've got a parking lot that is a type of car? Or you can use
the instance of the parking lot to drive the car? Really not sure
I'm seeing what you are up to here.

it's a parking lot for parkinglots, you're confusing things.

J

 

[Soulshift]

I think I would probably have CompositeIsoWidget derived from IsoWidget.
Since the standard library probably already has all the container support
you need, I don't see a problem with whatever duplication there would be
with CompositeWidget.

You could also consider protected inheritance, which allows you to inherit
the implementation of a general-purpose container class that does most of
the work, while the public interface of each composite Widget class only
allows the correct kind of Widgets.

DW

Thanks for the suggestions. Probably the only thing that will work is
the template idea, as the behaviour of a CompositeWidget is not
trivially duplicatible. Implementing a template solution will take a
lot of work, but it's good to know that there is a nice way to do it.