When designing software systems, understanding relationships between objects is crucial. Three fundamental relationships in object-oriented design (OOD) are association, aggregation, and composition. These relationships define how objects interact and depend on each other.

This blog will explore:

1. What are association, aggregation, and composition?
2. How they differ from one another?
3. When to use which relationship?
4. Real-world examples and UML representations

1. Association

Definition: Association is a general relationship between two or more objects. It represents a "uses" or "knows" relationship where objects can interact but do not depend on each other for their existence.

🔹 Key Characteristics:

✔ Objects can exist independently.

✔ Can be one-to-one (1:1), one-to-many (1:N), or many-to-many (M:N).

✔ Usually bidirectional but can be unidirectional.

💡 Example: A Student and a Teacher. A student can have multiple teachers, and a teacher can teach multiple students.

UML Representation:

Student  --------  Teacher  

A simple line represents an association.

2. Aggregation

Definition: Aggregation is a special type of association where one object (whole) contains other objects (parts). However, the parts can exist independently of the whole.

🔹 Key Characteristics:

✔ Represents a "Has-A" relationship.

✔ The child (part) can exist independently of the parent (whole).

✔ Denoted by a hollow diamond in UML.

💡 Example: A Department and Professors. A department consists of multiple professors, but professors can exist even if the department is removed.

UML Representation:

Department ◇------  Professor  

The hollow diamond on the Department side indicates aggregation.

3. Composition

Definition: Composition is a stronger form of aggregation where the contained object (part) cannot exist without the container (whole). When the whole is deleted, the parts are also deleted.

🔹 Key Characteristics:

✔ Represents a strong "Has-A" relationship.

✔ The part object is fully dependent on the whole object.

✔ Denoted by a filled diamond in UML.

💡 Example: A House and Rooms. If the house is destroyed, the rooms do not exist independently.

UML Representation:

House ◆------  Room  

The filled diamond on the House side indicates composition.

4. Differences Between Association, Aggregation, and Composition

5. When to Use Which?

• Use Association when objects need to interact but should not be dependent (e.g., Student ↔ Teacher).
• Use Aggregation when objects form a whole-part relationship, but the part can exist independently (e.g., Department ↔ Professor).
• Use Composition when objects form a strong dependency, and parts cannot exist without the whole (e.g., House ↔ Room).

6. Code Examples

Association Example (Student ↔ Teacher)

class Teacher {
    String name;
    Teacher(String name) { this.name = name; }
}

class Student {
    String name;
    Teacher teacher;  // Association with Teacher
    Student(String name, Teacher teacher) {
        this.name = name;
        this.teacher = teacher;
    }
}

Aggregation Example (Department ↔ Professor)

import java.util.List;

class Professor {
    String name;
    Professor(String name) { this.name = name; }
}

class Department {
    String name;
    List<Professor> professors; // Aggregation (Hollow Diamond)
    Department(String name, List<Professor> professors) {
        this.name = name;
        this.professors = professors;
    }
}

Composition Example (House ↔ Room)

import java.util.ArrayList;
import java.util.List;

class Room {
    String type;
    Room(String type) { this.type = type; }
}

class House {
    private List<Room> rooms;

    House() {
        rooms = new ArrayList<>();
        rooms.add(new Room("Living Room"));
        rooms.add(new Room("Bedroom"));
    }

    // No getter for rooms: rooms are part of the house and cannot exist independently.
}

7. Final Thoughts

Understanding association, aggregation, and composition helps in designing robust and scalable systems.

• Association is for simple relationships.
• Aggregation allows flexibility by keeping parts independent.
• Composition enforces strong ownership, ensuring parts are tied to their whole.

Choosing the right relationship improves software maintainability, reusability, and clarity. Always analyze your use case and pick the relationship that best models real-world scenarios.

Do you have any questions or need further clarification? Let’s discuss!