Aggregation Versus Composition

Aggregation versus Composition

The distinction between aggregation and composition depends on context.

Take the car example mentioned in another answer - yes, it is true that a car exhaust can stand "on its own" so may not be in composition with a car - but it depends on the application. If you build an application that actually has to deal with stand alone car exhausts (a car shop management application?), aggregation would be your choice. But if this is a simple racing game and the car exhaust only serves as part of a car - well, composition would be quite fine.

Chess board? Same problem. A chess piece doesn't exist without a chess board only in certain applications. In others (like that of a toy manufacturer), a chess piece can surely not be composed into a chess board.

Things get even worse when trying to map composition/aggregation to your favorite programming language. In some languages, the difference can be easier to notice ("by reference" vs. "by value", when things are simple) but in others may not exist at all.

And one last word of advice? Don't waste too much time on this issue. It isn't worth it. The distinction is hardly useful in practice (even if you have a completely clear "composition", you may still want to implement it as an aggregation due to technical reasons - for example, caching).

Implementation difference between Aggregation and Composition in Java

Composition

final class Car {

  private final Engine engine;

  Car(EngineSpecs specs) {
    engine = new Engine(specs);
  }

  void move() {
    engine.work();
  }
}

Aggregation

final class Car {

  private Engine engine;

  void setEngine(Engine engine) {
    this.engine = engine;
  }

  void move() {
    if (engine != null)
      engine.work();
  }
}

In the case of composition, the Engine is completely encapsulated by the Car. There is no way for the outside world to get a reference to the Engine. The Engine lives and dies with the car. With aggregation, the Car also performs its functions through an Engine, but the Engine is not always an internal part of the Car. Engines may be swapped, or even completely removed. Not only that, but the outside world can still have a reference to the Engine, and tinker with it regardless of whether it's in the Car.

Aggregation vs Composition vs Association vs Direct Association

Please note that there are different interpretations of the "association" definitions. My views below are heavily based on what you would read in Oracle Certification books and study guides.

Temporary association

A usage inside a method, its signature or as a return value. It's not really a reference to a specific object.

Example: I park my Car in a Garage.

Composition association

A so-called "STRONG relationship": The instantiation of the linked object is often hard
coded inside the constructor of the object. It cannot be set from
outside the object. (Composition cannot be a many-to-many
relationship.)

Example: A House is composed of Stones.

Direct association

This is a "WEAK relationships". The objects can live independent and there are usually setters or other ways to inject the dependent objects.

Example: A Car can have Passengers.

Aggregation association

Very similar to a Direct association. It's also a "WEAK relationship" with independent objects. However here the associated objects are a crucial part of the containing object.

Example: A Car should have Tires.

Note: Both Direct associations and Aggregation associations are often generalized as "Associations". The difference is rather subtle.

Understanding the Aggregation, Association, Composition

In concise

Association - There are two objects that know about each other, but they can't affect to each other's lifetime.

Composition - There are two classes: A and B.Object of the class A contains a class B object, and can't logically be created without class B.

Aggregation - is a variant of the "has a" association relationship; aggregation is more specific than association. It is an association that represents a part-whole or part-of relationship.

In your examples, 1, and 3 are Compositions, because they contain class B object.Example 4 is Association, because it only knows about class B and only uses it's object as a local variable.Example 2 is and Aggregation.

For more you can read in wiki
https://en.wikipedia.org/wiki/Class_diagram

EDITED:

Difference between Composition and Aggregation.

Composition relationship: When attempting to represent real-world whole-part relationships, e.g. an engine is a part of a car.

Aggregation relationship: When representing a software or database relationship, e.g. car model engine ENG01 is part of a car model CM01, as the engine, ENG01, may be also part of a different car model.

In your example 1, your create an object of class B in your class A.Based on your code you can't give the created object of class B to another object of class A.
But in your example 2, you are giving object B as an parameter.So you can create many objects of class A and give them the same object B

UML Diagram Help (Aggregation/Composition)

What is composition and aggregation ?

The composition and aggregation represents a whole/part relationship (UML 2.5, section 11.5.3.1):

A binary Association may represent a composite aggregation (i.e., a
whole/part relationship).

So if you use a diamond, you should first ask yourself if it's really a whole/part relationship, before thinking how objects are created or deleted.

Then composition have additional constraints over a shared aggregation. In a composition relationship (UML 2.5, section 9.5.3):

(...) the composite object has responsibility for the existence and storage
of the composed objects.
Composite aggregation is a strong form of
aggregation that requires a part object be included in at most one
composite object at a time. If a composite object is deleted, all of
its part instances that are objects are deleted with it.

Analysis of your specific diagramm

According to your diagram:

• The players exists only within a game (i.e. temporary identification not accounts existing across several games). The composition could make sense, as players can be seen as parts of the game.
• The hand exist only in relation to a player. That makes sense. But is it really a composition relationship ? Is the hand a part of a player ? Is the player composed of hands ? Wouldn't a player have several hands sequentially but not in the same time ? I really have my doubt about a composition here; I'd represent this with a normal 1 player to many hands association.
• The game aggregates several decks. I don't know your game but I'd expect one deck. If several decks are used, and the decks only exists within a game (similarly to the players), I'd rather see a composition instead of an aggregation. Alternatively you could mean not the deck, but the deck together with its state. In this case, I'd opt for a one to many association and not a composition (the deck+state would not be a component of your game, but define the state of the game).
• A deck is the aggregation of cards that exist independently of the deck. This troubles me a lot, as my world experience has always shown that a card is part of a deck. If I find an isolated card somewhere I always look for it's deck. I'd therefore rather expect a composition between cards and deck.
• Finally a hand is the aggregation of several cards, which seems to make sense. Note that this is not incompatible with a composition between the deck and the card.

Association vs. Aggregation

This is a very arguable question. As Martin explains in the answer, the Order aggregates the Product. And this can be considered true. Grady Booch in his "Object-Oriented Analysis and Design" brings a similar example for association - a sale is associated with products in that sale, and vice versa. And a sale doesn't aggregate products. So all examples should be domain-specific, because from another point of view the association may become more specific. Another example is the composition of Documents using Paragraphs.

So everything in this field strongly depends on the context. This is the OOP.

You can try to apply your knowledge to a particular project you are going to design. I would recommend you to read Grady Booch's book, if you haven't done it yet. Lots of books have been written since it, but it is still the Bible of OO*.

---

Related Topics