From Design Pattern by GoF:
An object reference representing a part-of or aggregation relationship is indicated by an arrowheaded line with a diamond at the base. The arrow points to the class that is aggregated (e.g., Shape). An arrowheaded line without the diamond denotes acquaintance (e.g., a LineShape keeps a reference to a Color object, which other shapes may share). A name for the reference may appear near the base to distinguish it from other references Another useful thing to show is which classes instantiate which others. We use a dashed arrowheaded line to indicate this, since OMT doesn't support it. We call this the "creates" relationship. The arrow points to the class that's instantiated. In Figure B.lc, CreationTool creates LineShape objects.
when object A aggregates object B, must object A have a field member referencing object B?
when object A acquaints object B, must object A have a field member referencing object B?
when object A instantiates object B, must object A have a field member referencing object B?
Instantiation creates an object instance (many languages are using the
new
keyword for this) while aggregation describes the relationship between objects (that are already created or instantiated). To prevent confusion I have to point out that all terms used in this example like aggregation are used in the context of Martin Fowler, who has introduced a different definition or phrasing in contrast to the UML standard definition.From your diagram:
Aggregation
given are the two class definitions
Drawing
andShape
that have, according to your provided diagram, a relationship which is called aggregation, which by definition describes a shared lifetime of those two objects. This means aDrawing
'consists' of an arbitrary number ofShapes
or to be more precise aShape
is part of aDrawing
. When the lifetime of the owner (Drawing
) ends, then also the lifetime ofShape
will end:Because the relationship between
Drawing
andShape
is an aggregation the instantiation of the typeShape
occurs inside the owners constructor (opposed to outside the owner object in case of acquaintance).Acquaintance
The other relationship that is pictured by the diagram is the acquaintance. Acquaintance exist between the object of type
LineShape
andColor
. This means aLineShape
uses aColor
.Color
will live independent from its owningLineShape
object. The dashed line between the objectsCreationTool
andLineShape
describes an instantiation (create). This means thatCreationTool
creates the instance ofLineShape
. This is required since opposed to aggregation acquaintance describes an independent lifetime of both objects.Color
could be shared between otherShape
objects. This requires the related objects ofLineShape
, theColor
object, to be instantiated outside the owner (and not inside the owner's constructor like in an aggregation scenario):Because the relationship between
LineShape
andColor
is an acquaintance the instantiation occurs outside the owners constructor (opposed to inside the owner object like in an aggregation scenario). This way a single instance ofColor
could be shared among multiple owners.As you can see in the code examples both relations (or relations in general) require the reference, pointing to the related object(s), to be stored inside the owning object. The only difference is when looking at where the owned object was created. This circumstance will describe the special form of the relationship: was the related object instantiated outside the owner (acquaintance) or was it instantiated inside the owner (aggregation)? This means you can distinguish this two types of relationship by looking at the constructor (or instantiation): is the related object instance passed to the constructor or a setter method of the owner (acquaintance) or is the owner's constructor parameter-less or setter-less (aggregation)?
For instantiation the requirement of a field is a different story. We can say that when
CreationTool
instantiatesLineShape
it does not need a field to store a reference to this object. But in case of theColor
theCreationToolobject
can store the reference to theColor
instance in a field in order to reuse it (share it) when creating newLineShape
instances, since an instance ofColor
is needed to satisfy the constructor ofLineShape
. So if a field to store the reference to the created instance inside the creator is required is totally optional in first place and depends on the context.It should be mentioned at this point, that in case of acquaintance, another way to 'inject' the owned object instance is to use a setter method:
Using the constructor should be the prefered way whenever possible.
Another note, just to make it more complete: when the language used to implement such relationships has automatic memory management (garbage collection), then the aspect of lifetime controlling is no more relevant. Everything becomes acquaintance in M. Fowlers world (or aggregation in the UML world), since as long as there is any references stored to the owned object instance (e.g. when exposing the instance via a getter method), the garbage collector won't destruct this instance and it will continue to live - independent from the owner.