Inheritence/substitutability dilemma

[arnaudk]

I have two unrelated types of data elements (objects) which I want to hold in two related types of containers, one for each element type. But this seems contradictory - for consistency, it seems that either

1. the containers should be unrelated through inheritance, or
2. the elements should be related through inheritance.

The problem with (a) is that I'd like to specify a base class interface for the containers which necessarily relates them through inheritance, and the problem with (b) is that the elements are have very different methods and members so defining a base class for those elements to shoehorn them into the container base class interface would be kind of a hack.

In other words, my elements do not follow the principle of substitutabilit y of objects that are related through inheritence, but their containers do, apart from a single method addelement() which adds the disparate elements to the containers.

What would be a good solution to this dilemma? Has anyone come across such a situation before?

(I originally posted this question as part of a larger question in this thread which which did not attract many responses, so I'm splitting up my question into different parts and skipping implementation details as suggested there.)

[weaknessforcats]

I suggest your containers contain objects of class T. That is, use a template for the containers.

Now the objects that are contained have very different interfaces so you can't use a base class for these interfaces. Instead, implement a Visitor on the container and get at your methods for the T objects using a Visitor object for that T.

There is an article in the C/C++ Articles forum on the Visitor design pattern. In that article are code samples that implement exactly what your are looking for.

[arnaudk]

Thanks for the reply, w4cats. I have a look at that article again.

[RRick]

From your post, the 2 different objects are stored in two different containers. As W4cats suggested, templates are a good way to define the containers. They will hold the correct type of object and make sure you don't mix and match them incorrectly.

Now you have two containers that are related. Okay, make a class that has both of the containers as members. In this case, the parent class has the two containers as children (i.e. is-a relation). Now, the parent class has access both containers and the parent public API can define what needs to be done to both containers.

[arnaudk]

Hi, RRick, and thanks for your reply!

make a class that has both of the containers as members. ... (i.e.
is-a relation).

That would appear to be more of a has-a relationship to me. The parent class here does not serve as an interface to its children in a way that I can use polymorphic base class pointers. Indeed, I have two types of containers, but more than two containers. So using a parent class means I'll have to know in advance how many containers there will be, unless I use a composite, is that what you're alluding to? Even then I'd still need a (more complicated) base class for the elements and containers...