Re: How should a container class "know" its contained objects?

Thanks for all your posts. I wonder if I am confusing people by using
the word "container".

In my case I am not talking about a language supplied container, such
as an array, list, dictionary, etc. I am talking developing a
software class (to mirror what's going on in the domain) that holds of
a number of other objects.

Because this top level class is comprised of ("has") a number of other
classes, I refer to it as a container. Maybe I shouldn't do that.
Here's a contrived example. The business example is much more
complicated, so I hope this weak parallel will make enough sense:

Let's imagine that your problem space deals with a concept known as a
PartsDrawer. In your domain, the user must define a number of
PartsDrawers, each of which can contain:

-One Toolbelt, which has several abilities of its own, and contains
some woodscrews.

-Any number of Magic-Bins, which have several abilities of their own,
and contain some wood screws.

....

Now, there are a few things I'm trying to accommodate in the design:

1. I would like the design to mimic the domain. As such, I would have
a PartsDrawer class that can hold (have/contain) one Toolbelt and any
number of Magic-Bins

2. We have a business rule that says the objects put into a
PartsDrawer can't have a same colored screw in them. That is, if you
have a red screw in a Toolbelt, that's in a particular PartsDrawer,
you can't add a Magic-bin to this particular PartsDrawer if that Magic-
bin also contains a red screw.

....

Now, it turns out, that in the software design Toolbelt and Magic-Bins
both inherit from a common class WoodScrewHolder, which provide some
common abilities for classes that deal with woodscrews and allows the
enumeration of woodscrews held by those classes.

The question then becomes: should PartsDrawer decalre variables of
type WoodScrewHolder (the base class) to hold the instances of
Toolbelt and Magic-Bins, or should the variables be of type Toolbelt
and Magic-bins specifically?


As far as #2, the business rule about non-repeating colors, I view
this as a responsibility of the PartsDrawer. It should prevent things
being added to it (the Toolbelt and any number of Magic-bins) which
contain the same color screw. To achieve this (the ability to get at
and check the woodscrews) PartsDrawer only needs the abilities of the
base class, WoodScrewHolder, which allows enumeration over the screws.
From this point of view I'd say that PartsDrawer should declare its
variables to be of type WoodScrewHolder, so that if the actual items
assigned later become more specialized (we end up with a Super-Magic-
Bin, which would also inherit from WoodScrewHolder) they could still
be assigned to the PartsDrawer without modifying the parts drawer.


But here's the kicker to that: Code outside of these classes will want
to be accessing the Toolbelt and the Magic-Bin, using their
specialized type. That is, this other code can't get it's job done if
it has to be constrained to accessing the Toolbelt and Magic-Bin as
WoodScrewHolders.

If we we declare variables of type WoodScrewHolders in PartsDrawer,
this outside code could certainly downcast them to the more specific
types (Toolbelt and Magic-Bins) but this feels odd too..Doesn't it
seem strange the the outside classes would know the "most specialized"
identity of these contained classes while the PartsDrawer only knows
them through their most general type?

Sorry if this doesn't make sense. This has been a very confusing
project for me with all sorts of weird domain relationships..

Michael




.