Association is a concept in object-oriented programming that models the relationship between two or more classes. Association involves using other classes to build more complex classes.

Association represents a has-a relationship. For example, consider the computer as an object. Computer has-a motherboard, keyboard, speaker, etc.

The concept of association is often used in the real world, and it should be the same in software development. A car is not an engine; it has one. And a coffee machine has a grinder and a brewing unit, but it is none of them. The car and the coffee machine integrate an engine, grinder and brewing unit via their external APIs to compose a higher level of abstraction and provide more significant value to their users.

Pros

• Reuse existing code
  • The main reason to use association is that it allows you to reuse code without modeling an is-a association (as you do by using inheritance). You design a class to keep a reference to an object and to use it in one or more of its methods.
• Make your code easier to maintain and modify
  • As long as a class gets only used by your own code, you can easily change it without worrying about external use.

There are three types of associations: association, aggregation and composition.

🔗 Association

Besides “association" being the generic term that englobes every association type, there is a specific scenario that can't be an aggregation nor a composition.

Since aggregations and composition can only be unidirectional, a bidirectional relationship is the remainder of the association categories (and it's called "association"). This can be a little confusing, because aggregations and compositions are associations. But a bidirectional association isn't an aggregation nor a composition.

This being said, let's talk about this remainder of the association categories and let's call it "Association".

Association is a semantically weak relationship between otherwise unrelated objects. An association is a “using” relationship (named "has-a") between two or more objects in which the objects have their own lifetime and there is no owner. In an association, you see the parts that build the whole object.

A bidirectional association has no parent/child, being two independent objects. The objects that are part of the association relationship can be created and destroyed independently.

In an association, you associate by reference, which de-couples the lifetimes of the two objects. The whole may not have a part, or it may have a different part at different times. Different wholes may share the same part. De-allocating the whole won't automatically de-allocate the part. Association by reference allows for the part to be aware of its whole.

<aside> 💡 As an example, a class Person can have an optional "married to" property, which references to another Person. Here, we have a bidirectional relationship, without parent/child. This is our remainder association (it isn't an aggregation nor a composition).

</aside>

🛫 Aggregation

Aggregation is a typical whole/part or parent/child relationship, and the lifetime of the owned object does not depend on the lifetime of the owner.

It represents Has-A’s relationship and it is an unidirectional association. For example, a department can have students but vice versa is not possible and thus unidirectional in nature

As in an association, you can aggregate by reference, which de-couples the lifetimes of the two objects. De-allocating the whole won't automatically de-allocate the part. Aggregation by reference allows for the part to be aware of its whole.