Re: Design Problem Aggregation
From: H. S. Lahman (h.lahman_at_verizon.net)
Date: Mon, 10 May 2004 20:36:49 GMT
Responding to Merlin...
Basically I agree with Rauscher...
> Imagine the following classes (A class diagram will help)
> BASE, A, B, C, D, E, F, G.
> A, B, C, D, G inherit from BASE.
> E, F inherit from D.
> Class E has a member (aggregation by value) of type A.
> Class F has a member (aggregation by value) of type B.
E and F only seem to exist to collect As and Bs, but not Cs. I would
look for a more direct set of relationships...
> Class G has a member that is container that can accept objects of type
> D. As D is the base class of E and F we can add to the container
> objects of type E or F. I have made the container type safe in this
> I wanted G to be a collection of objects of type A or B but never C so
> I introduced an abstract class D and made the container of that type
> so it would only accept objects of base type D. However, although this
> looks ok, I am not happy with the extra work it has created.
> As I need to access the interface to A and B, I need to repeat all
> that interface in E and F. A and B have many member functions and I
> dont want to rewrite all that interface in E and F and delegate the
> calls to the aggregate.
Since G only collects Ds, then something like this should enforce the A
or B but not C constraint:
| | * 1
[C] [D] --------------- [Container]
IOW, keep [Container] out to the hierarchy because it isn't a [Base]; it
is just a collection class that collects certain [Base] members. (I
assume there is some valid basis for saying an A, B, or C is a Base.)
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
Pathfinder Solutions -- Put MDA to Work