I have a design opinion. I have 3 models in mind, and I don't
particularly like them, so maybe someone can suggest or help justify.
I have a set of essentially unrelated classes (about 6).
class Foo;
class Bar;
class Bat;
I have a container-ish class that holds many of those other classes
and other meta-data:
class Stuff {
public:
vector<pair<string, Foo *> > foos;
vector<pair<string, Bar *> > bars;
vector<pair<string Bat *> > bats;
}
So here's the problem. I need to store the unrelated classes in a
somewhat related way. I need to sort them all together in insert
order, for later retrieval. What I mean is that later, I need to walk
the container somehow and pull out al the Foos, Bars, and Bats,
intermingled with each other, in the order they were inserted.
So, I have dreamed up three answers, none of which I really like.
1) Make a generic base class, Stuff_Item, which is a base class for
Foo, Bar, Bat, etc. Store all Foo, Bar, Bat in a single vector.
Stuff_Item::stuff_type() returns and enum that callers use to
determine the type of the thing held. Callers then up-cast.
2) Make a generic base class, Stuff_Item, which is not a base class,
and which has methods stuff_type() and stuff_index(). stuff_type
returns an enum that callers use to determine the type of the thing
held. stuff_index returns an index (or an iterator) into a type-
specific vector. Keep a seperate vector of Stuff_Items. Callers can
then use that as a (database-style) index.
3) Make a Stuff::Item inner class, which holds an enum of pointers to
Foo, Bar, Bat.. That inner class exposes is_foo(), is_bar(), is_bat()
methods, and get_foo(), get_bar(), get_bat() methods. Just store one
vector of Stuff::Item.
Thoughs, justifications, other ideas?