Re: Design Problem Aggregation

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 05/10/04 

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
> way.
>
> 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:

            [Base]
               |
     +---------+-----------+
     | | * 1
    [C] [D] --------------- [Container]
                           A
                           |
                  +--------+--------+
                  | |
                 [A] [B]

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
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
(888)-OOA-PATH

Relevant Pages

  • Re: Design Problem Aggregation
    ... > Classes A, D, F, G, J inherit from BASE. ... > Class H has a member of type C. ... As G is the base class of H and I we can add to the container ... this case that it must be a reference or pointer to BASE (note that H and I ...
    (comp.lang.cpp)
  • Re: Design Problem Aggregation
    ... Something else also has to inherit from A or else B is an identity set ... > Class H has a member of type C. ... As G is the base class of H and I we can add to the container ... > that interface in H and I. C and E have many member functions and I ...
    (comp.object)
  • Re: Design Problem Aggregation
    ... >Class E has a member of type A. ... As D is the base class of E and F we can add to the container ... >that interface in E and F. A and B have many member functions and I ... This is called the Interface Segregation Principle. ...
    (comp.object)
  • Re: Design Problem Aggregation
    ... Classes A, D, F, G, J inherit from BASE. ... Class H has a member of type C. ... Class J has a member that is container that can accept objects of type ... As I need to access the interface to C and E, ...
    (comp.object)
  • Re: Design Problem Aggregation
    ... > A, B, C, D, G inherit from BASE. ... > Class E has a member (aggregation by value) of type A. ... > Class G has a member that is container that can accept objects of type ...
    (comp.lang.cpp)