Difference aggregation, acquaintance and composition (as used by Gang Of Four)

Question

I have been reading Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma et al. and got to the part explaining aggregation and acquaintance (page 22-23). Here is an excerpt (sorry if it is too long but I deemed all of it to be important to explain this question):

Consider the distinction between object aggregation and acquaintance and how differently they manifest themselves at compile- and run-times. Aggregation implies that one object owns or is responsible for another object. Generally we speak of an object having or being part of another object. Aggregation implies that an aggregate object and its owner have identical lifetimes.

Acquaintance implies that an object merely knows of another object. Sometimes acquaintance is called ”association” or the “using” relationship. Acquainted objects may request operations of each other, but they aren’t responsible for each other. Acquaintance is a weaker relationship than aggregation and suggests much looser coupling between objects.

[…]

Ultimately, acquaintance and aggregation are determined more by intent than by explicit language mechanisms. The distinction may be hard to see in the compile-time structure, but it's significant. Aggregation relationships tend to be fewer and more permanent than acquaintance. Acquaintances, in contrast, are made and remade more frequently, sometimes existing only for the duration of an operation. Acquaintances are more dynamic as well, making them more difficult to discern in the source code.

The confusing part for me is that aggregation described here has traits of composition: a composing object manages other objects and their lifetimes are bound.

On the other hand acquaintance defined in that excerpt has traits of aggregation: an aggregating object knows about other objects but it does not manage them.

Also the part

Sometimes acquaintance is called “association” or the “using” relationship.

is confusing as I thought that both aggregation and composition are forms of association with aggregation being the less coupling one.

Can it be that the authors are referring to aggregation as acquaintance and to composition as aggregation, or am I missing something?

Answer 1

What I have been taught is as you write:

Can it be that the authors are referring to aggregation as acquaintance and to composition as aggregation or am I missing something?

Yes. My understanding is:

1. At the beginning, when you are doing the (rough) analysis, think in terms of association. In this phase it is usually enough.

2. Later, when you describe the (detailed) design, you need to decide the ownership of the objects, their lifecycle, instantiation, cleanup etc.

   Specify the associations in deeper detail - divide them into two groups:

   • aggregation (the more free relationship where the objects may live independently) and
   • composition (the more tight relationship where one object is responsible for the life cycle of the other).

However, not depending which of the terminology you are using (the one of the Gang of Four or the UML definition as I described here), all the terms mean relationship between whole objects, and not only that a single method of an object uses a local variable (or a parameter, which is just a special type of a local variable) with another object.

class Car {
    // There is an association between Car and RegistrationPlate.
    // This association is either composition or aggregation.
    // The type of association is *not* deferrable from the syntax here.
    // This is purely the design decision and depends on many things,
    // both technical and business logic.
    // In some countries the registration plates are movable among cars,
    // in others they are cancelled when you scrap the car.
    RegistrationPlate registrationPlate;

    // Technically, there is an association between Car and List
    // but we rarely call it like that. Instead we say
    // "there is one to many association between Car and Tyre"
    // and the List is viewed just as an implementation detail.
    List<Tyre> tyres;

    // There is neither association nor composition nor aggregation 
    // between Car and Engine and Fuel
    // but instead  Car <<uses>> Engine   and   Car <<uses>> Fuel.
    void doSomething(Fuel fuel) {
        Engine engine = new Engine();
        // (method parameter fuel is just a special case of a local method variable)
        ...
    }
}

In the code, both the aggregation and the composition might look the same at the first glance, especially in the languages with garbage collector (like Java, Kotlin or C#), where the programmers do not have to care so much about the clean-up [Note 1]. However, the difference is in the responsibility for the life-cycle of the associated object:

• In case of the composition, it is mandatory that the "container" object is responsible for all the necessary cleanup of its component.
• In case of the aggregation, the situation is much more complicated, because the aggregated object has (can have) its own life and you must be very careful to properly implement the cleanup.

---

[Note 1] Even in languages with garbage collector, you also often have to think about clean-up, such as closing opened connections, releasing file handles, and taking care of effectively losing reference to objects so they are GC eligible - not forgetting unused objects in collections, using weak references, or other techniques. This is out of scope of this question.

Answer 2

Composition: When a class composes of a data member of another class.

Class A
{
   B ObjB;
}

Aggregation: When method of a class creates object of some other class within its scope

void A::methA()
{
   B* ObjB= new B();
   delete ObjB;
}

Acquintance/Using: When method of a class accepts reference to object of another class as argument

void A:methA (B& objB) 
{

}

Answer 3

Can it be that the authors are referring to aggregation as acquaintance and to composition as aggregation, or am I missing something?

OMT was published in 1991, UML in 1997, and the book Design Patterns in 1994. So the authors use OMT aggregation to refer to UML composite aggregation (AKA composition).

Here are the UML definitions:

• Aggregation (AKA the having relationship) is a part–whole relationship, meaning that the whole cannot exist without the part (not the other way round). The part is an essential attribute of the whole. E.g. a car (the whole) and its engine (the part) are in aggregation since a car needs its engine to exist.

• Association (AKA the acquaintance relationship or using relationship) on the other hand is not a part–whole relationship. One object is an accidental attribute of the other. E.g. a car and its owner are in association since a car does not need its owner to exist.

Note. — Aggregation can be subdivided into two categories: shared aggregation where the part can exist without the whole, and composite aggregation (AKA composition, or unique aggregation as I like to call it) where the part cannot exist without the whole.

---

References

Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.

Consider the distinction between object aggregation and acquaintance and how differently they manifest themselves at compile- and run-times. Aggregation implies that one object owns or is responsible for another object. Generally we speak of an object having or being part of another object. Aggregation implies that an aggregate object and its owner have identical lifetimes.

Acquaintance implies that an object merely knows of another object. Sometimes acquaintance is called ”association” or the “using” relationship. Acquainted objects may request operations of each other, but they aren’t responsible for each other. Acquaintance is a weaker relationship than aggregation and suggests much looser coupling between objects.

Copying and Comparing: Problems and Solutions by Peter Grogono and Markku Sakkinen.

We distinguish essential and accidental attributes of an object.{Footnote: This distinction is based loosely on Aristotle’s categories.} An essential attribute is indisputably a part of the object; an accidental attribute is another object that is related in some way to the object in question but is not a part of it. For example, if the object in question is an instance of class Car, we would consider the attribute engine to be essential but the basic value distanceTravelled and the reference owner to be accidental. The distinction between “accidental” and “essential” is orthogonal to that between “reference” and “containment”. The model permits all four possibilities. When an attribute is represented by a reference, it is the referent object itself, not the reference, that is the accidental or essential attribute.

Accidental attributes are intended as a generalization of associations. An association is a “structural relationship between peers” where “peers” are classes at the same conceptual level. An association is a kind of accidental attribute but it is not the only kind. Associations are usually implemented as references to other full-fledged objects, although more elaborate implementations have been proposed. But objects may also contain counters, flags, descriptors, and other attributes that are needed by the application software but are conceptually not part of the object.

The distinction between essential and accidental is not always obvious. As a rule of thumb, the relationship between two objects is an association (and therefore accidental) if destroying one object does not logically entail destroying the other, otherwise one object is an attribute of the other. Similarly, an attribute is accidental if removing it from the object does not destroy the basic integrity of the object.