System Design (LLD)Relationships Between Objects

Relationships Between Objects

LevelBeginner

Duration60 mins

TopicRelationships Between Objects

1 / 4

Association — Objects That Know Each Other

The Language of Object Connections

In object-oriented design, objects rarely exist in isolation. A Customer places an Order. A Doctor treats a Patient. A Teacher instructs Students. An Employee works for a Company. These aren't just business relationships—they're structural relationships that we encode directly into our software.

Association is the most fundamental relationship type in object-oriented design. It represents the simple yet profound concept that one object "knows about" another. Understanding association is the foundation upon which all other relationship types—dependency, aggregation, and composition—are built.

This page dives deep into association: what it means, how to identify it, how to model it correctly, and how to implement it in ways that lead to maintainable, flexible systems.

What You Will Learn

By the end of this page, you will understand: (1) The precise definition of association and how it differs from other relationships, (2) How to identify associations from requirements, (3) Unidirectional vs bidirectional associations, (4) Multiplicity and cardinality in associations, (5) How to implement associations in code, and (6) Common pitfalls and best practices.

What Is Association?

Association is a structural relationship that describes a connection between two or more classes, indicating that objects of one class are connected to objects of another class.

At its core, association answers the question: "Does this object need to know about or interact with that object to fulfill its responsibilities?"

Unlike inheritance (which models "is-a" relationships) or implementation (which models "can-do" relationships), association models "uses" or "has-a" relationships in their most general form.

Formal Definition

In UML terms, an association is a relationship between classifiers that describes a set of tuples whose values refer to instances of those classifiers. More simply: it's a structural connection that allows one object to access and use another object.

Key Characteristics of Association:

Structural Connection: Association represents a link that exists for some duration—not just a fleeting method call, but an ongoing relationship that's part of the system's structure.
Navigability: Associated objects can access and communicate with each other. The association provides a "path" for message passing.
Independent Existence: In a pure association, both objects exist independently. Destroying one doesn't automatically destroy the other.
Semantic Richness: Associations often have names, roles, and multiplicities that describe the nature and constraints of the relationship.

Association vs Other Relationship Types
Relationship Type	What It Models	Example	Key Distinction
Association	Objects that know about each other	Student enrolls in Course	Structural link with independent lifecycles
Dependency	Objects that temporarily use each other	PaymentProcessor uses Logger	Transient, method-level usage only
Aggregation	Whole-part where parts can exist alone	Department has Employees	Parts survive if whole is destroyed
Composition	Whole-part where parts cannot exist alone	House has Rooms	Parts are destroyed with the whole

Identifying Associations from Requirements

One of the most important skills in object-oriented design is reading requirements and identifying the associations they imply. This is both an analytical and creative process.

The Linguistic Approach: Natural language often reveals associations through verbs and verb phrases that connect nouns. Consider these requirement statements:

Association-Revealing Verb Patterns

•"A Customer places an Order" → Customer is associated with Order
•"A Teacher teaches multiple Courses" → Teacher is associated with Course
•"An Author writes Books" → Author is associated with Book
•"A Student enrolls in Classes" → Student is associated with Class
•"An Employee reports to a Manager" → Employee is associated with Manager (which is also an Employee)
•"A Flight connects two Airports" → Flight is associated with Airport

Verbs That Suggest Associations:

Verb Type	Examples	Relationship Implication
Action verbs	creates, handles, manages, processes	Actor-target association
Possessive verbs	has, owns, contains, holds	Ownership-style association
Connective verbs	connects, links, references, points to	Structural connection
Transactional verbs	purchases, borrows, reserves, books	Transaction participant association
Organizational verbs	belongs to, reports to, is part of	Hierarchical association

Not Every Verb Implies Association

Be careful not to over-model. Action verbs that describe one-time operations (like "calculates" or "validates") often indicate dependencies rather than associations. The key question is: "Does this object need to maintain a lasting reference to the other?" If the answer is "only during one method call," it's likely a dependency, not an association.

The Responsibility Test: Another way to identify associations is to ask what responsibilities each class has. If Class A has a responsibility that requires knowledge about instances of Class B, there's likely an association.

Example Analysis:

Consider this requirement: "The system should allow customers to view their order history and track current orders."

Customer needs to know about its Orders (to display order history)
Therefore, Customer is associated with Order
The verb "view" reveals navigability: Customer navigates to Orders
"Their order history" suggests a one-to-many relationship: one Customer, many Orders

Directionality — Unidirectional vs Bidirectional Associations

One of the most important design decisions when modeling associations is directionality—which objects can "see" which other objects.

Navigability is the technical term for whether one object can access another through the association. A navigable association means the source object holds a reference to the target object.

Unidirectional Association

•Only one class knows about the other
•Navigation is possible in one direction only
•Simpler to implement and maintain
•Reduces coupling between classes
•Example: Order → Customer (Order knows its Customer, but Customer doesn't store Orders directly)
•Implementation: Only one class has a reference field

Bidirectional Association

•Both classes know about each other
•Navigation is possible in both directions
•More complex to maintain consistency
•Creates tighter coupling
•Example: Student ↔ Course (Students know their Courses, Courses know their Students)
•Implementation: Both classes have reference fields

Design Principle

Prefer unidirectional associations unless bidirectionality is genuinely required. Bidirectional associations create synchronization challenges—if Student adds a Course, the Course must also add the Student, and vice versa. This dual-update requirement is a common source of bugs. Only add bidirectionality when both navigation directions are needed for core functionality.

UnidirectionalAssociation.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
// UNIDIRECTIONAL: Order knows about Customer, but not vice versa
public class Customer {
    private String customerId;
    private String name;
    private String email;
    
    // Customer has NO reference to Orders
    // Orders are retrieved via a Repository or Service when needed
    
    public Customer(String customerId, String name, String email) {
        this.customerId = customerId;
        this.name = name;
        this.email = email;
    }
    
    // Getters and business methods...
}
 
public class Order {
    private String orderId;
    private Customer customer;  // Unidirectional: Order → Customer
    private List<OrderItem> items;
    private OrderStatus status;
    
    public Order(String orderId, Customer customer) {
        this.orderId = orderId;
        this.customer = customer;
        this.items = new ArrayList<>();
        this.status = OrderStatus.PENDING;
    }
    
    public Customer getCustomer() {
        return this.customer;
    }
    
    // Order can access Customer, but Customer doesn't know about this Order
}
 
// To get a Customer's orders, use a repository pattern:
public interface OrderRepository {
    List<Order> findByCustomerId(String customerId);
}

When to Use Bidirectional Associations:

Frequent Navigation in Both Directions: If your use cases regularly require navigating from A to B and from B to A, bidirectional may be justified.
Domain Model Accuracy: Some domain relationships are inherently bidirectional. A Professor teaches Courses, and Courses are taught by Professors—both perspectives are equally important.
Performance Considerations: When repository lookups would be too expensive, direct navigation via bidirectional associations can improve performance.

Managing Bidirectional Consistency:

BidirectionalAssociation.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
// BIDIRECTIONAL: Student ↔ Course with proper synchronization
public class Student {
    private String studentId;
    private String name;
    private Set<Course> enrolledCourses;  // Navigable to Course
    
    public Student(String studentId, String name) {
        this.studentId = studentId;
        this.name = name;
        this.enrolledCourses = new HashSet<>();
    }
    
    // Package-private method for Course to use
    void addCourseInternal(Course course) {
        this.enrolledCourses.add(course);
    }
    
    void removeCourseInternal(Course course) {
        this.enrolledCourses.remove(course);
    }
    
    // Public method that maintains bidirectional consistency
    public void enrollIn(Course course) {
        if (this.enrolledCourses.add(course)) {
            course.addStudentInternal(this);  // Sync the other side
        }
    }
    
    public void dropCourse(Course course) {
        if (this.enrolledCourses.remove(course)) {
            course.removeStudentInternal(this);  // Sync the other side
        }
    }
    
    public Set<Course> getEnrolledCourses() {
        return Collections.unmodifiableSet(enrolledCourses);
    }
}
 
public class Course {
    private String courseId;
    private String title;
    private Set<Student> enrolledStudents;  // Navigable to Student
    
    public Course(String courseId, String title) {
        this.courseId = courseId;
        this.title = title;
        this.enrolledStudents = new HashSet<>();
    }
    
    // Package-private method for Student to use
    void addStudentInternal(Student student) {
        this.enrolledStudents.add(student);
    }
    
    void removeStudentInternal(Student student) {
        this.enrolledStudents.remove(student);
    }
    
    // Public method that maintains bidirectional consistency
    public void enrollStudent(Student student) {
        if (this.enrolledStudents.add(student)) {
            student.addCourseInternal(this);  // Sync the other side
        }
    }
    
    public void removeStudent(Student student) {
        if (this.enrolledStudents.remove(student)) {
            student.removeCourseInternal(this);  // Sync the other side
        }
    }
    
    public Set<Student> getEnrolledStudents() {
        return Collections.unmodifiableSet(enrolledStudents);
    }
}

Multiplicity and Cardinality

Multiplicity defines how many instances of one class can be associated with instances of another class. This is one of the most important constraints to specify when designing associations.

Getting multiplicity wrong leads to serious design flaws—a one-to-many relationship implemented as one-to-one will fail the moment a Customer places a second Order.

UML Multiplicity Notation
Notation	Meaning	Example
1	Exactly one	An Order has exactly one Customer
0..1	Zero or one (optional)	An Employee has zero or one assigned Laptop
*1.. **	One or more	An Order has one or more OrderItems
*0.. ** or *	Zero or more	A Customer has zero or more Orders
n	Exactly n	A Chess game has exactly 2 Players
n..m	Between n and m	A Project has 3..10 TeamMembers

Common Multiplicity Patterns:

Multiplicity in Practice

•One-to-One (1:1): Each instance of A associates with exactly one instance of B, and vice versa. Example: Person ↔ Passport (each person has one passport, each passport belongs to one person).
•One-to-Many (1:N): One instance of A associates with many instances of B, but each B associates with only one A. Example: Department → Employees (one department has many employees, each employee belongs to one department).
•Many-to-Many (M:N): Instances of A can associate with multiple instances of B, and vice versa. Example: Student ↔ Course (students enroll in many courses, courses have many students).
•Optional vs Required: Whether an association must exist (1 or 1..) or may exist (0..1 or 0..). Example: An Order must have a Customer (required), but a Customer may have zero Orders (optional).

Many-to-Many: The Design Trigger

Many-to-many associations often signal that there's a hidden concept in the domain. Student ↔ Course is actually Student ↔ Enrollment ↔ Course. The Enrollment captures additional data: enrollment date, grade, status. When you see many-to-many, ask: "Is there a relationship object hiding here?"

MultiplicityExamples.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
// ONE-TO-ONE: Person ↔ Passport
public class Person {
    private Passport passport;  // 0..1 — may be null
    
    public void issuePassport(Passport passport) {
        if (this.passport != null) {
            throw new IllegalStateException("Person already has a passport");
        }
        this.passport = passport;
    }
}
 
// ONE-TO-MANY: Department → Employees
public class Department {
    private List<Employee> employees;  // 0..* — empty list is valid
    
    public void addEmployee(Employee employee) {
        employees.add(employee);
        employee.setDepartment(this);  // Maintain bidirectional if needed
    }
}
 
public class Employee {
    private Department department;  // 1 — required, never null
    
    public Employee(Department department) {
        Objects.requireNonNull(department, "Employee must belong to a department");
        this.department = department;
    }
}
 
// MANY-TO-MANY: With intermediary class for rich relationships
public class Student {
    private List<Enrollment> enrollments;
}
 
public class Course {
    private List<Enrollment> enrollments;
}
 
public class Enrollment {  // The "relationship" object
    private Student student;
    private Course course;
    private LocalDate enrollmentDate;
    private Double grade;
    private EnrollmentStatus status;
    
    public Enrollment(Student student, Course course) {
        this.student = student;
        this.course = course;
        this.enrollmentDate = LocalDate.now();
        this.status = EnrollmentStatus.ACTIVE;
    }
}

Roles and Association Names

Well-designed associations include naming and role information that clarifies the purpose of the relationship. This is especially important when:

A class has multiple associations to the same target class
The nature of the association isn't obvious from the class names
The same class participates in an association with itself (self-association)

Association Names: Describe the nature of the relationship as a verb or verb phrase.

Person ——— works for ——→ Company
Student ——— enrolls in ——→ Course
Author ——— writes ——→ Book

Role Names: Describe what role each participating object plays in the association.

Employee —————→ Employee
   ↑               ↑
   |               |
  subordinate    manager

Self-Associations Require Roles

When a class associates with itself (like Employee manages Employee), role names are essential to distinguish the two ends. Without roles, the relationship is ambiguous: "An employee is related to an employee" tells us nothing. With roles: "An employee (as subordinate) reports to an employee (as manager)" is clear.

RolesExample.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
// Self-association with clear roles
public class Employee {
    private Employee manager;           // Role: manager (0..1)
    private List<Employee> subordinates;  // Role: subordinates (0..*)
    
    public void setManager(Employee manager) {
        if (this.manager != null) {
            this.manager.subordinates.remove(this);
        }
        this.manager = manager;
        if (manager != null) {
            manager.subordinates.add(this);
        }
    }
    
    public Employee getManager() {
        return manager;
    }
    
    public List<Employee> getSubordinates() {
        return Collections.unmodifiableList(subordinates);
    }
}
 
// Multiple associations to the same class with different roles
public class Flight {
    private Airport departureAirport;  // Role: departure
    private Airport arrivalAirport;    // Role: arrival
    
    // Without roles, we'd have ambiguous: "Flight has two Airports"
    // With roles, it's clear: departure and arrival airports
    
    public Flight(Airport departure, Airport arrival) {
        this.departureAirport = departure;
        this.arrivalAirport = arrival;
    }
}
 
public class Transaction {
    private Account sourceAccount;       // Role: source/sender
    private Account destinationAccount;  // Role: destination/receiver
    private Money amount;
    
    // Roles clarify which account is debited vs credited
}

Common Pitfalls and Anti-Patterns

Association design is fraught with common mistakes. Here are the most frequent anti-patterns and how to avoid them:

Association Anti-Patterns

•Overloaded Associations: Using a single association to model multiple conceptually different relationships. If Customer has both "preferred products" and "purchased products," these should be separate associations, not one overloaded "products" field.
•Bidirectional by Default: Making every association bidirectional "just in case." This adds complexity and synchronization bugs. Start unidirectional; add the reverse direction only when needed.
•Missing Multiplicity Constraints: Not specifying whether an association is optional or required, one or many. This leads to null-checking everywhere or runtime surprises.
•Naked Object References: Exposing mutable association references directly. If a getter returns a mutable List of associated objects, external code can modify the association without the owning object's knowledge.
•Circular Navigation Obsession: Creating complex circular navigation paths (A → B → C → D → A) that make the object graph hard to understand and serialize.
•Ignoring Relationship Objects: Forcing data onto the wrong class when a relationship class (like Enrollment, Membership, or Booking) would be more appropriate.

BadAssociation.java
1
2
3
4
5
6
7
8
9
10
11
12
13
// ❌ ANTI-PATTERN: Exposed mutable list
public class Order {
    private List<OrderItem> items;
    
    // BAD: External code can modify
    public List<OrderItem> getItems() {
        return items;  // Exposes internal state!
    }
}
 
// Usage that breaks encapsulation:
order.getItems().clear();  // Oops!
order.getItems().add(null);  // Oops!

GoodAssociation.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// ✅ CORRECT: Encapsulated collection
public class Order {
    private List<OrderItem> items;
    
    // Return unmodifiable view
    public List<OrderItem> getItems() {
        return Collections.unmodifiableList(items);
    }
    
    // Control modifications via methods
    public void addItem(OrderItem item) {
        items.add(item);
        item.setOrder(this);
    }
}

The God Object Trap

Watch out for classes that become central "hubs" with associations to everything. If your User class has direct associations to Orders, Payments, Reviews, Messages, Settings, Preferences, Notifications, Addresses, and PaymentMethods, you've likely created a God Object. Consider if some of these should be reached through services or repositories instead of direct associations.

Association Best Practices Checklist

Apply this checklist when designing associations to ensure your object relationships are well-formed:

Association Design Checklist

•Justify Every Association: Ask "Why does this object need to know about that object?" If there's no clear answer, the association may not be needed.
•Start Unidirectional: Begin with navigation in one direction. Add bidirectionality only when use cases genuinely require it.
•Specify Multiplicity: Always define whether the association is 1, 0..1, 1.., or 0.. on each end. Never leave this implicit.
•Consider Optionality: Is the association required (constructor parameter) or optional (setter, add method)?
•Use Role Names: When the purpose isn't obvious, or when there are multiple associations to the same class, add role names.
•Encapsulate Collections: Never expose mutable collections directly. Return unmodifiable views and provide add/remove methods.
•Look for Hidden Relationship Classes: If the association should carry data, extract a relationship class.
•Evaluate Lifecycle Impact: Will creating/destroying one object affect the other? If so, consider aggregation or composition instead.

Summary: Objects That Know Each Other

Association is the foundation of object relationships. Let's consolidate what we've learned:

Key Takeaways

•Association is structural: It represents an ongoing relationship where one object holds a reference to another, enabling navigation and communication.
•Identify from requirements: Look for verbs connecting nouns. "Customer places Order" reveals Customer → Order association.
•Prefer unidirectional: Bidirectional associations add complexity. Only add the reverse direction when genuinely needed.
•Multiplicity matters: Define 1, 0..1, 1.., or 0.. for each end. Getting this wrong leads to fundamental design flaws.
•Use roles for clarity: Role names disambiguate self-associations and multiple associations to the same class.
•Encapsulate associations: Control access through methods. Never expose mutable collections.
•Association ≠ Composition: In association, objects exist independently. The next pages cover relationships with lifecycle implications.

Coming Up Next:

Association is just the beginning. In the next page, we explore Dependency—the most transient form of relationship, where one object temporarily uses another without maintaining an ongoing reference. Understanding the distinction between association and dependency is crucial for reducing coupling and building maintainable systems.

Page Complete

You now understand association—the fundamental relationship type in object-oriented design. You can identify associations from requirements, choose appropriate directionality and multiplicity, and implement associations with proper encapsulation.

1 / 4

Loading learning content...

System Design (LLD)Relationships Between Objects

Relationships Between Objects

LevelBeginner

Duration60 mins

TopicRelationships Between Objects

1 / 4

Association — Objects That Know Each Other

The Language of Object Connections

This page dives deep into association: what it means, how to identify it, how to model it correctly, and how to implement it in ways that lead to maintainable, flexible systems.

What You Will Learn

What Is Association?

Association is a structural relationship that describes a connection between two or more classes, indicating that objects of one class are connected to objects of another class.

At its core, association answers the question: "Does this object need to know about or interact with that object to fulfill its responsibilities?"

Unlike inheritance (which models "is-a" relationships) or implementation (which models "can-do" relationships), association models "uses" or "has-a" relationships in their most general form.

Formal Definition

Key Characteristics of Association:

Structural Connection: Association represents a link that exists for some duration—not just a fleeting method call, but an ongoing relationship that's part of the system's structure.
Navigability: Associated objects can access and communicate with each other. The association provides a "path" for message passing.
Independent Existence: In a pure association, both objects exist independently. Destroying one doesn't automatically destroy the other.
Semantic Richness: Associations often have names, roles, and multiplicities that describe the nature and constraints of the relationship.

Association vs Other Relationship Types
Relationship Type	What It Models	Example	Key Distinction
Association	Objects that know about each other	Student enrolls in Course	Structural link with independent lifecycles
Dependency	Objects that temporarily use each other	PaymentProcessor uses Logger	Transient, method-level usage only
Aggregation	Whole-part where parts can exist alone	Department has Employees	Parts survive if whole is destroyed
Composition	Whole-part where parts cannot exist alone	House has Rooms	Parts are destroyed with the whole

Identifying Associations from Requirements

One of the most important skills in object-oriented design is reading requirements and identifying the associations they imply. This is both an analytical and creative process.

The Linguistic Approach: Natural language often reveals associations through verbs and verb phrases that connect nouns. Consider these requirement statements:

Association-Revealing Verb Patterns

•"A Customer places an Order" → Customer is associated with Order
•"A Teacher teaches multiple Courses" → Teacher is associated with Course
•"An Author writes Books" → Author is associated with Book
•"A Student enrolls in Classes" → Student is associated with Class
•"An Employee reports to a Manager" → Employee is associated with Manager (which is also an Employee)
•"A Flight connects two Airports" → Flight is associated with Airport

Verbs That Suggest Associations:

Verb Type	Examples	Relationship Implication
Action verbs	creates, handles, manages, processes	Actor-target association
Possessive verbs	has, owns, contains, holds	Ownership-style association
Connective verbs	connects, links, references, points to	Structural connection
Transactional verbs	purchases, borrows, reserves, books	Transaction participant association
Organizational verbs	belongs to, reports to, is part of	Hierarchical association

Not Every Verb Implies Association

Example Analysis:

Consider this requirement: "The system should allow customers to view their order history and track current orders."

Customer needs to know about its Orders (to display order history)
Therefore, Customer is associated with Order
The verb "view" reveals navigability: Customer navigates to Orders
"Their order history" suggests a one-to-many relationship: one Customer, many Orders

Directionality — Unidirectional vs Bidirectional Associations

One of the most important design decisions when modeling associations is directionality—which objects can "see" which other objects.

Navigability is the technical term for whether one object can access another through the association. A navigable association means the source object holds a reference to the target object.

Unidirectional Association

•Only one class knows about the other
•Navigation is possible in one direction only
•Simpler to implement and maintain
•Reduces coupling between classes
•Example: Order → Customer (Order knows its Customer, but Customer doesn't store Orders directly)
•Implementation: Only one class has a reference field

Bidirectional Association

•Both classes know about each other
•Navigation is possible in both directions
•More complex to maintain consistency
•Creates tighter coupling
•Example: Student ↔ Course (Students know their Courses, Courses know their Students)
•Implementation: Both classes have reference fields

Design Principle

UnidirectionalAssociation.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
// UNIDIRECTIONAL: Order knows about Customer, but not vice versa
public class Customer {
    private String customerId;
    private String name;
    private String email;
    
    // Customer has NO reference to Orders
    // Orders are retrieved via a Repository or Service when needed
    
    public Customer(String customerId, String name, String email) {
        this.customerId = customerId;
        this.name = name;
        this.email = email;
    }
    
    // Getters and business methods...
}
 
public class Order {
    private String orderId;
    private Customer customer;  // Unidirectional: Order → Customer
    private List<OrderItem> items;
    private OrderStatus status;
    
    public Order(String orderId, Customer customer) {
        this.orderId = orderId;
        this.customer = customer;
        this.items = new ArrayList<>();
        this.status = OrderStatus.PENDING;
    }
    
    public Customer getCustomer() {
        return this.customer;
    }
    
    // Order can access Customer, but Customer doesn't know about this Order
}
 
// To get a Customer's orders, use a repository pattern:
public interface OrderRepository {
    List<Order> findByCustomerId(String customerId);
}

When to Use Bidirectional Associations:

Frequent Navigation in Both Directions: If your use cases regularly require navigating from A to B and from B to A, bidirectional may be justified.
Domain Model Accuracy: Some domain relationships are inherently bidirectional. A Professor teaches Courses, and Courses are taught by Professors—both perspectives are equally important.
Performance Considerations: When repository lookups would be too expensive, direct navigation via bidirectional associations can improve performance.

Managing Bidirectional Consistency:

BidirectionalAssociation.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
// BIDIRECTIONAL: Student ↔ Course with proper synchronization
public class Student {
    private String studentId;
    private String name;
    private Set<Course> enrolledCourses;  // Navigable to Course
    
    public Student(String studentId, String name) {
        this.studentId = studentId;
        this.name = name;
        this.enrolledCourses = new HashSet<>();
    }
    
    // Package-private method for Course to use
    void addCourseInternal(Course course) {
        this.enrolledCourses.add(course);
    }
    
    void removeCourseInternal(Course course) {
        this.enrolledCourses.remove(course);
    }
    
    // Public method that maintains bidirectional consistency
    public void enrollIn(Course course) {
        if (this.enrolledCourses.add(course)) {
            course.addStudentInternal(this);  // Sync the other side
        }
    }
    
    public void dropCourse(Course course) {
        if (this.enrolledCourses.remove(course)) {
            course.removeStudentInternal(this);  // Sync the other side
        }
    }
    
    public Set<Course> getEnrolledCourses() {
        return Collections.unmodifiableSet(enrolledCourses);
    }
}
 
public class Course {
    private String courseId;
    private String title;
    private Set<Student> enrolledStudents;  // Navigable to Student
    
    public Course(String courseId, String title) {
        this.courseId = courseId;
        this.title = title;
        this.enrolledStudents = new HashSet<>();
    }
    
    // Package-private method for Student to use
    void addStudentInternal(Student student) {
        this.enrolledStudents.add(student);
    }
    
    void removeStudentInternal(Student student) {
        this.enrolledStudents.remove(student);
    }
    
    // Public method that maintains bidirectional consistency
    public void enrollStudent(Student student) {
        if (this.enrolledStudents.add(student)) {
            student.addCourseInternal(this);  // Sync the other side
        }
    }
    
    public void removeStudent(Student student) {
        if (this.enrolledStudents.remove(student)) {
            student.removeCourseInternal(this);  // Sync the other side
        }
    }
    
    public Set<Student> getEnrolledStudents() {
        return Collections.unmodifiableSet(enrolledStudents);
    }
}

Multiplicity and Cardinality

Multiplicity defines how many instances of one class can be associated with instances of another class. This is one of the most important constraints to specify when designing associations.

Getting multiplicity wrong leads to serious design flaws—a one-to-many relationship implemented as one-to-one will fail the moment a Customer places a second Order.

UML Multiplicity Notation
Notation	Meaning	Example
1	Exactly one	An Order has exactly one Customer
0..1	Zero or one (optional)	An Employee has zero or one assigned Laptop
*1.. **	One or more	An Order has one or more OrderItems
*0.. ** or *	Zero or more	A Customer has zero or more Orders
n	Exactly n	A Chess game has exactly 2 Players
n..m	Between n and m	A Project has 3..10 TeamMembers

Common Multiplicity Patterns:

Multiplicity in Practice

•One-to-One (1:1): Each instance of A associates with exactly one instance of B, and vice versa. Example: Person ↔ Passport (each person has one passport, each passport belongs to one person).
•One-to-Many (1:N): One instance of A associates with many instances of B, but each B associates with only one A. Example: Department → Employees (one department has many employees, each employee belongs to one department).
•Many-to-Many (M:N): Instances of A can associate with multiple instances of B, and vice versa. Example: Student ↔ Course (students enroll in many courses, courses have many students).
•Optional vs Required: Whether an association must exist (1 or 1..) or may exist (0..1 or 0..). Example: An Order must have a Customer (required), but a Customer may have zero Orders (optional).

Many-to-Many: The Design Trigger

MultiplicityExamples.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
// ONE-TO-ONE: Person ↔ Passport
public class Person {
    private Passport passport;  // 0..1 — may be null
    
    public void issuePassport(Passport passport) {
        if (this.passport != null) {
            throw new IllegalStateException("Person already has a passport");
        }
        this.passport = passport;
    }
}
 
// ONE-TO-MANY: Department → Employees
public class Department {
    private List<Employee> employees;  // 0..* — empty list is valid
    
    public void addEmployee(Employee employee) {
        employees.add(employee);
        employee.setDepartment(this);  // Maintain bidirectional if needed
    }
}
 
public class Employee {
    private Department department;  // 1 — required, never null
    
    public Employee(Department department) {
        Objects.requireNonNull(department, "Employee must belong to a department");
        this.department = department;
    }
}
 
// MANY-TO-MANY: With intermediary class for rich relationships
public class Student {
    private List<Enrollment> enrollments;
}
 
public class Course {
    private List<Enrollment> enrollments;
}
 
public class Enrollment {  // The "relationship" object
    private Student student;
    private Course course;
    private LocalDate enrollmentDate;
    private Double grade;
    private EnrollmentStatus status;
    
    public Enrollment(Student student, Course course) {
        this.student = student;
        this.course = course;
        this.enrollmentDate = LocalDate.now();
        this.status = EnrollmentStatus.ACTIVE;
    }
}

Roles and Association Names

Well-designed associations include naming and role information that clarifies the purpose of the relationship. This is especially important when:

A class has multiple associations to the same target class
The nature of the association isn't obvious from the class names
The same class participates in an association with itself (self-association)

Association Names: Describe the nature of the relationship as a verb or verb phrase.

Person ——— works for ——→ Company
Student ——— enrolls in ——→ Course
Author ——— writes ——→ Book

Role Names: Describe what role each participating object plays in the association.

Employee —————→ Employee
   ↑               ↑
   |               |
  subordinate    manager

Self-Associations Require Roles

RolesExample.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
// Self-association with clear roles
public class Employee {
    private Employee manager;           // Role: manager (0..1)
    private List<Employee> subordinates;  // Role: subordinates (0..*)
    
    public void setManager(Employee manager) {
        if (this.manager != null) {
            this.manager.subordinates.remove(this);
        }
        this.manager = manager;
        if (manager != null) {
            manager.subordinates.add(this);
        }
    }
    
    public Employee getManager() {
        return manager;
    }
    
    public List<Employee> getSubordinates() {
        return Collections.unmodifiableList(subordinates);
    }
}
 
// Multiple associations to the same class with different roles
public class Flight {
    private Airport departureAirport;  // Role: departure
    private Airport arrivalAirport;    // Role: arrival
    
    // Without roles, we'd have ambiguous: "Flight has two Airports"
    // With roles, it's clear: departure and arrival airports
    
    public Flight(Airport departure, Airport arrival) {
        this.departureAirport = departure;
        this.arrivalAirport = arrival;
    }
}
 
public class Transaction {
    private Account sourceAccount;       // Role: source/sender
    private Account destinationAccount;  // Role: destination/receiver
    private Money amount;
    
    // Roles clarify which account is debited vs credited
}

Common Pitfalls and Anti-Patterns

Association design is fraught with common mistakes. Here are the most frequent anti-patterns and how to avoid them:

Association Anti-Patterns

•Overloaded Associations: Using a single association to model multiple conceptually different relationships. If Customer has both "preferred products" and "purchased products," these should be separate associations, not one overloaded "products" field.
•Bidirectional by Default: Making every association bidirectional "just in case." This adds complexity and synchronization bugs. Start unidirectional; add the reverse direction only when needed.
•Missing Multiplicity Constraints: Not specifying whether an association is optional or required, one or many. This leads to null-checking everywhere or runtime surprises.
•Naked Object References: Exposing mutable association references directly. If a getter returns a mutable List of associated objects, external code can modify the association without the owning object's knowledge.
•Circular Navigation Obsession: Creating complex circular navigation paths (A → B → C → D → A) that make the object graph hard to understand and serialize.
•Ignoring Relationship Objects: Forcing data onto the wrong class when a relationship class (like Enrollment, Membership, or Booking) would be more appropriate.

BadAssociation.java
1
2
3
4
5
6
7
8
9
10
11
12
13
// ❌ ANTI-PATTERN: Exposed mutable list
public class Order {
    private List<OrderItem> items;
    
    // BAD: External code can modify
    public List<OrderItem> getItems() {
        return items;  // Exposes internal state!
    }
}
 
// Usage that breaks encapsulation:
order.getItems().clear();  // Oops!
order.getItems().add(null);  // Oops!

GoodAssociation.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// ✅ CORRECT: Encapsulated collection
public class Order {
    private List<OrderItem> items;
    
    // Return unmodifiable view
    public List<OrderItem> getItems() {
        return Collections.unmodifiableList(items);
    }
    
    // Control modifications via methods
    public void addItem(OrderItem item) {
        items.add(item);
        item.setOrder(this);
    }
}

The God Object Trap

Association Best Practices Checklist

Apply this checklist when designing associations to ensure your object relationships are well-formed:

Association Design Checklist

•Justify Every Association: Ask "Why does this object need to know about that object?" If there's no clear answer, the association may not be needed.
•Start Unidirectional: Begin with navigation in one direction. Add bidirectionality only when use cases genuinely require it.
•Specify Multiplicity: Always define whether the association is 1, 0..1, 1.., or 0.. on each end. Never leave this implicit.
•Consider Optionality: Is the association required (constructor parameter) or optional (setter, add method)?
•Use Role Names: When the purpose isn't obvious, or when there are multiple associations to the same class, add role names.
•Encapsulate Collections: Never expose mutable collections directly. Return unmodifiable views and provide add/remove methods.
•Look for Hidden Relationship Classes: If the association should carry data, extract a relationship class.
•Evaluate Lifecycle Impact: Will creating/destroying one object affect the other? If so, consider aggregation or composition instead.

Summary: Objects That Know Each Other

Association is the foundation of object relationships. Let's consolidate what we've learned:

Key Takeaways

•Association is structural: It represents an ongoing relationship where one object holds a reference to another, enabling navigation and communication.
•Identify from requirements: Look for verbs connecting nouns. "Customer places Order" reveals Customer → Order association.
•Prefer unidirectional: Bidirectional associations add complexity. Only add the reverse direction when genuinely needed.
•Multiplicity matters: Define 1, 0..1, 1.., or 0.. for each end. Getting this wrong leads to fundamental design flaws.
•Use roles for clarity: Role names disambiguate self-associations and multiple associations to the same class.
•Encapsulate associations: Control access through methods. Never expose mutable collections.
•Association ≠ Composition: In association, objects exist independently. The next pages cover relationships with lifecycle implications.

Coming Up Next:

Page Complete

1 / 4