Class Relationships: Association, Aggregation, and Composition

Hello! Welcome back to your course on Low-Level Design.

In our last lesson, we took the first step in creating our design blueprint by identifying the core entities, their attributes, and their behaviors. However, these entities currently exist in isolation. A system's power comes not just from its objects, but from how they interact and are connected.

Today, we will build on that foundation to model the relationships between classes. Specifically, we will focus on three fundamental types of relationships: association, aggregation, and composition. Understanding the nuances between these is crucial for building robust, maintainable systems and for clearly articulating your design decisions in an interview.

The Spectrum of Relationships

In object-oriented design, not all relationships are created equal. They exist on a spectrum from weak to strong. We will explore three key points on this spectrum:

Association: A weak "uses-a" relationship.
Aggregation: A stronger "has-a" relationship.
Composition: The strongest "part-of" relationship.

Let's begin by understanding the foundational relationship: association.

Association: The "Uses-A" Relationship

Association is the most general relationship between two classes. It simply means that objects of two separate classes are linked and can interact with each other. They have their own independent lifecycles. Think of it as a "uses-a" or "knows-about" relationship.

A classic example is a Driver and a Car. A Driver uses a Car, but the Car can exist without that specific Driver, and the Driver certainly exists without the Car.

To understand the key characteristics of association, including how we represent multiplicity (e.g., one-to-one, one-to-many) and directionality, let's watch a segment from a detailed video on UML.

Basics of LLD | UML Diagram in detail | Association Vs Aggregation Vs Composition | VERY imp!!

This video by Keerti Purswani provides a clear explanation of the Association relationship, covering its notation, directionality (unidirectional vs. bidirectional), and the concept of multiplicity.

Watch from 08:07 to 15:58. Focus on understanding: How a simple line represents a bidirectional association (both classes know each other). How an arrow indicates a unidirectional association (one class knows about the other). The concept of multiplicity, which defines how many instances of one class can be related to one instance of another (e.g., 1, *, 1..*).

As the video explains, an association is typically represented in code by one class holding a reference to an object of another class as a member variable.

Aggregation and Composition: The "Has-A" Relationships

Now, let's move to two more specific—and often confused—types of relationships: Aggregation and Composition. Both represent a "whole-part" or "has-a" relationship, but they differ in one critical aspect: the strength of that relationship and the dependency of the lifecycles.

Aggregation is a weak "has-a" relationship. The "part" can exist independently of the "whole". For example, a Department has Professors. If the department is closed, the professors still exist.
Composition is a strong "has-a" relationship, also called a "part-of" relationship. The "part" cannot exist without the "whole". Its lifecycle is tied to the owner. For example, a House is composed of Rooms. If you demolish the house, the rooms are destroyed with it.

The distinction between these two is a very common interview topic. Getting it right demonstrates a solid grasp of OO principles.

Basics of LLD | UML Diagram in detail | Association Vs Aggregation Vs Composition | VERY imp!!

Let's dive deep into the differences between Aggregation and Composition with the same video. The examples provided here are excellent for building an intuitive understanding.

Watch from 15:58 to 24:36. Pay close attention to the core idea: Lifecycle Dependency: Can the 'part' object exist without the 'whole' object? The 'part-of' test: For Composition, the child is an integral part of the parent (e.g., a hand is part of a body). Shared Ownership: A key insight is that if a 'part' object's instance can be shared among multiple 'whole' objects, it's Aggregation, not Composition. An instance of a House can't be shared, but an instance of a Professor could potentially be shared between departments.

Translating Relationships to Java Code

Now that we have the concepts, let's see how they are typically implemented in Java. Since you have experience with Java, mapping these abstract concepts to concrete code structures will solidify your understanding.

The following article from Baeldung provides clear code examples and UML diagrams for all three relationships.

Composition, Aggregation, and Association in Java

This article, 'Composition, Aggregation, and Association in Java' from Baeldung, is a fantastic resource that shows how these relationships are modeled in code.

Read sections 2 ('Composition'), 3 ('Aggregation'), and 4 ('Association'). As you read, focus on: The UML notation for each: filled diamond for Composition, empty diamond for Aggregation, and a line/arrow for Association. The Java implementation detail for Composition: The article suggests using a non-static inner class. This is a powerful way to enforce that tight lifecycle coupling because a non-static inner class instance cannot exist without an instance of the outer class. The implementation for Aggregation/Association: These are both modeled with simple object references. The difference between them is purely logical and based on the design intent, not a specific language feature.

A Visual Summary

To help you remember the key differences, here is a helpful table that compares Association, Aggregation, and Composition side-by-side.

Comparison of Association, Aggregation, and Composition — This table summarizes the core definition, relationship type, object lifecycle dependency, and UML representation for Association, Aggregation, and Composition.

And here is a quick visual reference for the UML notations, which will be the focus of our next lesson.

UML Class Diagram Relationships Reference — This image shows the standard UML notation for various class relationships, including Composition (filled diamond), Aggregation (hollow diamond), and Association (line/arrow).

Test your understanding!

Let's revisit the Parking Lot system from our previous lesson. We identified the following core entities: ParkingLot, Level (or ParkingFloor), ParkingSpot, and Vehicle.

How would you model the relationships between these classes? Choose between Association, Aggregation, and Composition for each pair.

ParkingLot and Level
Level and ParkingSpot
ParkingSpot and Vehicle

Think about the lifecycle dependency for each. Can a Level exist without a ParkingLot? Can a ParkingSpot exist without a Level? Can a Vehicle exist without a ParkingSpot?

Show answer

Here's a standard way to model these relationships:

ParkingLot and Level: Composition.
- A ParkingLot is composed of one or more Levels. A Level is an integral part of a ParkingLot and cannot exist on its own. If the ParkingLot is demolished, the Levels cease to exist.
- UML: A line from ParkingLot to Level with a filled diamond at the ParkingLot end. Multiplicity: 1 on the ParkingLot side, 1..* (one or more) on the Level side.
Level and ParkingSpot: Composition.
- Similarly, a Level is composed of ParkingSpots. The spots are physically part of the level. They have no meaning or existence outside the context of their Level.
- UML: A line from Level to ParkingSpot with a filled diamond at the Level end. Multiplicity: 1 on the Level side, 1..* on the ParkingSpot side.
ParkingSpot and Vehicle: Aggregation (or Association).
- This one is more nuanced. A ParkingSpot can "have a" Vehicle parked in it. However, the Vehicle's lifecycle is completely independent of the ParkingSpot. The Vehicle existed before it was parked and will exist after it leaves.
- Aggregation is a good fit: It represents a temporary "whole-part" relationship where the ParkingSpot contains a Vehicle. UML would be a line with an empty diamond at the ParkingSpot end. Multiplicity: 1 on the ParkingSpot side, 0..1 (zero or one) on the Vehicle side.
- A weaker Association could also be argued, where a ParkingSpot simply "is associated with" or "references" a Vehicle. In code, both look similar. The key is to justify your choice based on the strength of the "has-a" relationship you intend to model. Aggregation is often preferred here to signify the containment aspect, even if temporary.

Conclusion

Excellent work today. You've now learned how to define the connections that turn a collection of individual classes into a structured, cohesive system. Mastering these relationships is fundamental to good object-oriented design.

Key Takeaways:

Association ("uses-a"): A general relationship between objects with independent lifecycles.
Aggregation ("has-a"): A whole-part relationship where the part can exist independently of the whole.
Composition ("part-of"): A strong whole-part relationship where the part cannot exist independently. Its lifecycle is tied to the whole.
The Litmus Test: The primary question to ask is, "If I delete the container object, does it make sense for the contained object to also be deleted?" If yes, it's Composition. If no, it's Aggregation.

In our next lesson, we will take everything we've learned so far—entities, attributes, behaviors, and now relationships—and combine them to create UML class diagrams to visually represent the object-oriented design. This will be the capstone of our initial design phase, giving you a powerful tool to communicate your LLD solutions.