• Thorsten Reitz
In aggregation, a whole data structure is made of parts belonging to one or more classes, such as a student belonging to multiple classes in their course of studies. Similar to composition, aggregation is a form of object combination. In software engineering, we often make a distinction between composition and aggregation:
- In aggregation, the lifecycle of the contained object is independent of the lifecycle of the containing object. The contained object (“containee”) can thus exist independently and be shared by more than one containing object.
- In composition, the lifecycle of the contained object is bound to the lifecycle of the containing object. There is exactly one object that owns the contained objects.
In aggregation, the container is incomplete when it’s missing the containee. A car without wheels isn’t complete, but the wheel can be mounted on a different car. Note that the encoding for the Association pattern is the same as for aggregation.
In aggregation, there is a containing class and a contained class. They are connected through an aggregation association which points from the containing class to the contained class:
|Please note that we create a new
When to use
Aggregation is a very versatile, well-supported pattern, and has several applicable uses:
- When there is a whole-part relationship between the objects
- When the lifecycle of the containees is linked to more than one container
- When inheritance is not applicable because the
is-astatement is not true and would break proper encapsulation.
When not to use
Aggregation implies a contains/contained relationship, and provides looser coupling than composition in terms of ownership and lifespans. It is thus not suitable for coupling of all types of closely related objects:
- You want to relate to an object where there is no aggregation (e.g. neighboringHouse)
- You want to combine objects that have a fully dependant lifecycle
XML Schema Example
A potential schema structure for the aggregation pattern is as follows:
In line 23, we define the contained property like any other property in the sequence. We declare it to be of type
ex:OwnerType. This schema allows us to do different types of encodings for the instance, as described below.
XML Instance Example
Instances using this pattern are usually encoded using a by-reference encoding to enable many-to-many relationships:
This section provides information when and how this pattern can be implemented on different types of platforms.
Composition is well-supported by all types of storage backends. In-line encoding in document-oriented backends has the advantage of not requiring joins.
This pattern can be implemented on XML-based platforms without special considerations.
This pattern can be implemented on object-oriented platforms without special considerations.
Many GIS applications support nested composition structures to some degree. As an example, ArcGIS geodatabases support Relationship classes and client-sied Relates, which you can use to define both aggregation and composition associations between different classes. However, it’s not possible to use nested properties for styling or in many analytic tools. For this purpose, you have to use client-side Joins.