Difference aggregation, acquaintance and compositi

Question

I have been reading Design Patterns: Elements of Reusable Object-Oriented Software and got to the part explaining aggregation and acquaintance. 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 -> composing object contains/manages other objects and their life-cycles are bound.

On the other hand acquaintance defined in that excerpt has traits of aggregation -> aggregating object only knows about the 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. In the analysis view, think in terms of association.
2. In the design view, specify each association 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).

Answer 2

@Honza Zidek is absolutely correct and to find more clear understanding use this link Association, Aggregation, Composition,

Answer 3

I can only provide an answer of aggregation for now.

Aggregation has the relationship of "part-of". For example a wheel is a part of a car. The car cannot exist without its wheels.

Answer 4

As per my understanding, aggregation refers to whole-part relationship. And the acquaintance refers to a using kind of relationship. This acquaintance is more weaker form of relationship than aggregation. Say for an instance you create a reference to an object inside a method/operation. This is more frequent than aggregation and lasts very short period. The reference exists only until the method returns, contrary to the entire life cycle of the object.

Answer 5

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) 
{

}