Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Composition

Reply
Thread Tools

Composition

 
 
Denis Remezov
Guest
Posts: n/a
 
      04-21-2004
fog wrote:
>
> 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
 
Reply With Quote
 
 
 
 
Denis Remezov
Guest
Posts: n/a
 
      04-21-2004
Denis Remezov wrote:
>

[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
 
Reply With Quote
 
 
 
 
fog
Guest
Posts: n/a
 
      04-21-2004
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!


 
Reply With Quote
 
Sharad Kala
Guest
Posts: n/a
 
      04-21-2004

"fog" <(E-Mail Removed)> wrote in message
news:dEohc.5542$(E-Mail Removed)...

[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


 
Reply With Quote
 
Claudio Puviani
Guest
Posts: n/a
 
      04-21-2004
"fog" <(E-Mail Removed)> wrote
> 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


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Aggregation vs. composition Rick Osborn Java 11 08-31-2009 08:45 AM
Can Tbird save a mail composition - periodically? default Firefox 5 10-16-2005 02:50 PM
composition or inheritance for a jdialog - Java 1 04-11-2005 01:53 PM
Mozilla Mail composition spaces on screen quincey cavenaugh Firefox 8 02-14-2004 06:01 PM
Need Composition Editor Tutorial John Schutkeker Java 0 10-17-2003 03:40 PM



Advertisments