Composition

[Denis Remezov]

Given:

class A;

and B "has-a" A. The composition relationship between A and B can be
implemented in three ways:

[snip]

As Claudio remarked, #1 is composition, #2 is not; #3, well, #3 still
can model composition, and in many cases, technically, it's the only way
to go. It's just not required to necessarily represent composition.

Which method is better design?

It depends on what you need to do.

#1: B makes copies of components A or constructs new ones, who will die
just before itself. If this is the exact intent, then #1 is the right
choice. Class A must be a complete type at the point of definition of B.
You may want to avoid this scheme if, e.g., objects A exist elsewhere,
get cloned just for the purpose of becoming components of B, and are big
and expensive to copy. A's lifetime coincides (up to the finer details of construction/destruction)
with that of its host B.

#2: Components A must be created elsewhere. B should require a guarantee
that A doesn't get destructed prematurely, or some form of mechanism to
ensure that (e.g. reference counting). Type A can be incomplete where
B is defined. Components A cannot be re-assigned or re-created. Objects
of B cannot be default-constructed. A is created before B and should live
longer or at least as long. It can be shared between multiple objects
of B.

#3: The most general scheme, it can model #1 but at the cost of the
inconveience of a pointer and overhead of manual handling/freestore
allocation. It can imitate #2 with a slight syntactic difference.
If #1 or #2 fit you perfectly then use them.
Use this one if you need more choices:
B and A can be coupled quite loosely, their lifetimes can overlap in any
combination. Components A can be destructed, re-assigned or re-created.
They can be shared between multiple objects of B. B can be default
constructed. As in #2, you need to make sure component A is valid for
as long as B is using it. Type A can be incomplete where B is defined.
It can also be a polymorphic base class, e.g. an abstract class, with
all possibilities that are unavailable in #1.

Denis

 

[Denis Remezov]

[snips]


#1: B makes copies of components A or constructs new ones, who will die
just before itself.

Oops, that should read "just after".

[snips]

Denis

 

[fog]

Given:

class A;

and B "has-a" A. The composition relationship between A and B can be
implemented in three ways:
===================
# 1.
class B
{
A a;
};
====================
# 2.
A a1;
class B
{
A& a;
};
====================
# 3.

class B
{
A* a;
public:
B(A* a1) : a(a1) { }
};

main()
{
A a;
B b(&a);
....
}
=====================
How to implement #2, specifically to initialize "A& a"?
Which method is better design?
Thanks for your help!

 

[Sharad Kala]

[snip]

=====================
How to implement #2, specifically to initialize "A& a"?

B(A& o):a(o){
}

Which method is better design?

Depends on what you want.
If the member could point to different A objects then A* should be used.
If you know it's going to refer to the same A object then A&.
You don't want to deal with pointers/references then use A, but then class A
should be fully defined and each B object has _atleast_ the size of an A object.

-Sharad

 

[Claudio Puviani]

Given:

class A;

and B "has-a" A. The composition relationship between A and B can be
implemented in three ways:
===================
# 1.
class B
{
A a;
};

This is composition.

====================
# 2.
A a1;
class B
{
A& a;
};

This is NOT composition. You're simply referencing an external object.

====================
# 3.

class B
{
A* a;
public:
B(A* a1) : a(a1) { }
};

Same as # 2. This is NOT composition. You're simply referencing an external
object.

main()
{
A a;
B b(&a);
...
}
=====================
How to implement #2, specifically to initialize "A& a"?
Which method is better design?

It's not a matter of "better". Only #1 models composition, so the other two
examples are meaningless in this context.

Claudio Puviani