TITLE: dealing with collections of heterogeneous objects

(Newsgroups: comp.lang.c++,comp.object, 15 Apr 98)


KIST: Jim Kist

> How would I go about representing a collection of heterogeneous object?
> The objects all have the variables name, address, city, state and dollar
> amount, and the services Delete, Copy and Print in common. Each object
> has additional variables, objects and services  that others may or may
> not have.  I want these objects in a collection so that a present a view
> of the collection to the user. The user can scroll through this view and
> choose the object they wish to manipulate. Any ideas would be greatly
> appreciated. Thanks in advance,


OTTINGER: Tim Ottinger <ottinger@oma.com>

As always (almost) with OO, you have a wealth of options. The hard
part isn't finding *a* way, but choosing among the many.  I assume you
are using C++ (because of cross-posting to comp.lang.c++).

Now there are a few things you have to work out. One is just collecting
them all.

C++ containers can't really handle truly unrelated objects. There has
to be a relationship established between them.  There are invasive
and non-invasive ways of doing this.

You will need to create an abstract base class that captures the
common protocol (methods) of the classes.  Call the base class
X for our discussion, okay (I don't know enough about your
problem to give it a cool name)? The base class should give
some read-only access to the variables (accessor functions).

Okay. Now you can have a container that holds pointers to
the base class. Now the trick is to have the heterogenous
objects "masquerade" behind X pointers.

There is an invasive way (that has lots of merit): you can go
back and edit all of these classes to derive from X. Now a
pointer to whatever class (call them Y1..Yn, okay?) can be
substituted as a pointer to X:
      list<X*> theList;
      Y1 * theObject = new Y1;
      Y2 * anotherOne = new Y2;
      theList.push_back(theObject);
      theList.push_back(anotherOne);

Now you have a container of (somewhat) heterogenous
objects.  For any particular object in the list, you can call
any of the functions defined in the class X.

Of course in other languages, you could have arrays of references
to "object", which accomplishes the same goal if all classes derive
from 'object'.

There's another way if you don't want to make all of the classes
derive from a common base. You can use something Doug
Schmidt's crew calls "external polymorphism" via templates.
Write me if you are interested in this.

There is another way to do this also, if you just want to show
the name, address, etc. You could simply create a data structure
that has only those attributes, and copy the date from the objects.
Preferably you make the data read-only. Then you use a
homogeneous container. When someone selects one, then you
look up the *real* object. This is not unusual for reference data
(stuff you look at but don't change). Then you use the real object
in every transaction you want. When you're done, you reselect
the reference data ("swatches") from the database. I know that
it doesn't sound very OO, but reference data really doesn't have
anything in the way of behavior. It's best represented as read-
only (const) structs.

When people get into trouble is when they decide to use these
"swatches" in real transactions. Don't do that. You want an object
that maintains its own integrity. For a real object that can be
manipulated, that means public methods and private data. For
a glob of reference data, being 'const' is enough. If it's immutable,
then the integrity is secure.

If you pardon me saying so, it looks like you might have a few
other things to consider.

One is whether "amount" is the correct name/idea for what
otherwise seems to be a "person" type of abstraction. Normally
people don't have "amount" as an attribute. Maybe "amount due" or
"pay rate" or something like that. But even in that case, there is
often some other object associated with "person" that carries the
"amount", like "account" or something. It might be important to
find that object. Of course, you don't have to. It's just a suggestion.

Also, you may want to reconsider having delete and print as members.
Especially 'print', because it ties the class to an output method. If you
just use it for debugging, it's cool enough. But it seems like it may not
have a 1:1 cardinality for all of time, as you may want to print it
various ways and on various devices. It would be cool if you can
have the 'print' be external to the object. But you don't have to change.
Just an idea.