Re: Design Problem Aggregation

From: Merlin (merlin2769_at_hotmail.com)
Date: 05/11/04


Date: 11 May 2004 11:20:04 -0700

Hi

Thank you both for your suggestions. What has been suggested works
well if no
class sits between BASE and A or BASE and B.

In order to make things clear, discard the original classes and
consider the following scenario.

Imagine we have the following classes

BASE, A, B, C, D, E, F, G, H, I, and J (class diagram will help)

Classes A, D, F, G, J inherit from BASE.

Class B inherits from A

Class C inherits from B

Class E inherits from D

Classes H and I inherit from G

Class H has a member (aggregation by value) of type C.
Class I has a member (aggregation by value) of type E.

Class J has a member that is container that can accept objects of type
G. As G is the base class of H and I we can add to the container
objects of type H or I. I have made the container type safe in this
way.

J is not a container, it has a member that is a container. My design
requires this. Also J does indeed inherit from BASE.

I wanted J to be a collection of objects of type C or E but never F or
even BASE so I introduced an abstract class G and made the container
of that type so it would only accept objects of base type G. However,
although this looks ok, I am not happy with the extra work it has
created.

As I need to access the interface to C and E, I need to repeat all
that interface in H and I. C and E have many member functions and I
dont want to rewrite all that interface in H and I and delegate the
calls to the aggregate.

How can I change my design to make it better and flexible?

If I do what you suggested I will have multiple inheritance and cyclic
dependencies. What else can I do to get a type safe container? Should
I put member functions in G to return the objects C and E? Doesnt that
break encapsulation?

Thanks Again,

Merlin



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
    ... > A, B, C, D, G inherit from BASE. ... > Class E has a member of type A. ... > Class G has a member that is container that can accept objects of type ... > that interface in E and F. A and B have many member functions and I ...
    (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)