Association vs. Aggregation [duplicate]

Question

This question already has an answer here:

• Aggregation versus Composition [closed] 12 answers

I have reviewed a lot of information about these things, but can't understand what is the difference between them? In Fowler's UML Distilled says that Aggreagation is strictly meaningless, so author recommends not to use it in diagrams. Explain, please, when I should use each of them and how it will influence on java code.

Answer 1

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*.

Answer 2

Association means two classes have some kind of relationship, could be anything really.

Composition and aggregation are two kinds of associations. The easiest way to distinguish them is thinking about "how hard" the relationship is. Think about what happens when you delete the owner object.

Aggregation, the aggregated object continues to live. (Think order <-> product, the product continues to live).

Composition, the aggregated object dies with the owner. (Think paragraphs <-> document, the paragraphs die with the document).

An aggregation can be argued to be meaningless since there isn't really much difference between drawing a line with an non-filled arrow (association), and a line with a non-filled diamond (aggregation). The relations are very similar. Line with filled diamond (composition) is however very different.

Answer 3

There are four kinds of Class relationships

1. Association: uses a
   Ex:a Class Man uses a Class Pen ( Pen is still there when man die )
2. Aggregation: has a
   Ex:a Class Man has a Class Car ( Car is still there when Man die )
3. Composition: owns a
   Ex:a Class Man owns a Class Heart ( When Man die, Heart die )
4. Inheritance: is a
   Ex:a Class Man is a Class Human ( Man is a Human )

A relationship between classes of objects

Inheritance>Composition>Aggregation>Association

Answer 4

Association is any relation between classes where instances of one class have a field reference to an instance of another class.

Composition is a "stronger" relation, meaning that one instance (parent) "owns" another one (child).

It is Aggregation that doesn't have any additional semantics other than being an association.

See more here: http://martinfowler.com/bliki/AggregationAndComposition.html

EDIT: You may add some special semantics to aggregation symbol, like "May be owned by maximum one parent at a time, but may change parents, or be an orphan." However, such extensions are your own, and are not defined in UML, as far as I know.

Answer 5

UML composition, aggregation and plain association are semantic concepts, not programming concepts. The meaning of them can be understood as follows:

• Composition: A consists of B; B is a part of A and hence cannot exist without A
• Aggregation: A owns B, B belongs to A
• Association: A uses B, A is related to B in a given way

(Composition and Aggregation are special types of associations.)

In Java, you may implement all of them in the same way. It's a conceptual difference.

Answer 6

There seems to be some debate on which word is which.

It has to do with parent-child relationships between objects and what happens to children when you delete the parent.

One scenario says that children have no life outside that of their parent, so they should be deleted when the parent is deleted. Think "DELETE CASCADE" in foreign keys and relational databases.

The other scenario says that children should persist beyond their parents, so they should not be deleted when their parent is deleted.

I'll leave it to others to argue which word describes each situation.