79:T4be,// 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 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 findByCustomerId(String customerId); }7a:T915,// BIDIRECTIONAL: Student ↔ Course with proper synchronization public class Student { private String studentId; private String name; private Set 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 getEnrolledCourses() { return Collections.unmodifiableSet(enrolledCourses); } } public class Course { private String courseId; private String title; private Set 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 getEnrolledStudents() { return Collections.unmodifiableSet(enrolledStudents); } }7b:T611,// 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 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 enrollments; } public class Course { private List 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; } }7c:T576,// Self-association with clear roles public class Employee { private Employee manager; // Role: manager (0..1) private List 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 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 }71:{"json":{"id":"seed_332c71acf3faadc0ab4cf641acd91d46","slug":"relationships-between-objects","category":"System Design (LLD)","topic":"Relationships Between Objects","title":"Relationships Between Objects","description":"Master the fundamental relationship types in object-oriented design: association, dependency, aggregation, and composition. Learn to identify, classify, and model object relationships that form the backbone of every well-designed system.","difficulty":"BEGINNER","estimatedMinutes":60,"pages":[{"id":"seed_b09a33b54d18b0db9539bb95135e1fdf","title":"Association — Objects That Know Each Other","order":0,"content":[{"id":"opening-hook","title":"The Language of Object Connections","content":[{"data":{"content":"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.\n\n**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.\n\nThis 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."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"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.","variant":"info"},"type":"callout"}]},{"id":"what-is-association","title":"What Is Association?","content":[{"data":{"content":"**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.**\n\nAt its core, association answers the question: \"Does this object need to know about or interact with that object to fulfill its responsibilities?\"\n\nUnlike 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."},"type":"text"},{"data":{"icon":"Info","title":"Formal Definition","content":"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.","variant":"note"},"type":"callout"},{"data":{"content":"**Key Characteristics of Association:**\n\n1. **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.\n\n2. **Navigability**: Associated objects can access and communicate with each other. The association provides a \"path\" for message passing.\n\n3. **Independent Existence**: In a pure association, both objects exist independently. Destroying one doesn't automatically destroy the other.\n\n4. **Semantic Richness**: Associations often have names, roles, and multiplicities that describe the nature and constraints of the relationship."},"type":"text"},{"data":{"rows":[["**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"]],"caption":"Association vs Other Relationship Types","headers":["Relationship Type","What It Models","Example","Key Distinction"]},"type":"table"}],"titleType":"number","titleNumber":1},{"id":"identifying-associations","title":"Identifying Associations from Requirements","content":[{"data":{"content":"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.\n\n**The Linguistic Approach**: Natural language often reveals associations through verbs and verb phrases that connect nouns. Consider these requirement statements:"},"type":"text"},{"data":{"items":["\"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"],"title":{"icon":"BookOpen","text":"Association-Revealing Verb Patterns","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**Verbs That Suggest Associations:**"},"type":"text"},{"data":{"rows":[["**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"]],"headers":["Verb Type","Examples","Relationship Implication"]},"type":"table"},{"data":{"icon":"AlertCircle","title":"Not Every Verb Implies Association","content":"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.","variant":"warning"},"type":"callout"},{"data":{"content":"**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.\n\n**Example Analysis:**\n\nConsider this requirement: *\"The system should allow customers to view their order history and track current orders.\"*\n\n- **Customer** needs to know about its **Orders** (to display order history)\n- Therefore, Customer is associated with Order\n- The verb \"view\" reveals navigability: Customer navigates to Orders\n- \"Their order history\" suggests a one-to-many relationship: one Customer, many Orders"},"type":"text"}],"titleType":"number","titleNumber":2},{"id":"directionality","title":"Directionality — Unidirectional vs Bidirectional Associations","content":[{"data":{"content":"One of the most important design decisions when modeling associations is **directionality**—which objects can \"see\" which other objects.\n\n**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."},"type":"text"},{"data":{"left":[{"data":{"items":["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"],"title":{"icon":"Target","text":"Unidirectional Association","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["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"],"title":{"icon":"Zap","text":"Bidirectional Association","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"icon":"Lightbulb","title":"Design Principle","content":"**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.","variant":"tip"},"type":"callout"},{"data":{"code":"$79","fileName":"UnidirectionalAssociation.java","showLineNumbers":true},"type":"code"},{"data":{"content":"**When to Use Bidirectional Associations:**\n\n1. **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.\n\n2. **Domain Model Accuracy**: Some domain relationships are inherently bidirectional. A Professor teaches Courses, and Courses are taught by Professors—both perspectives are equally important.\n\n3. **Performance Considerations**: When repository lookups would be too expensive, direct navigation via bidirectional associations can improve performance.\n\n**Managing Bidirectional Consistency:**"},"type":"text"},{"data":{"code":"$7a","fileName":"BidirectionalAssociation.java","showLineNumbers":true},"type":"code"}],"titleType":"number","titleNumber":3},{"id":"multiplicity-cardinality","title":"Multiplicity and Cardinality","content":[{"data":{"content":"**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.\n\nGetting 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."},"type":"text"},{"data":{"rows":[["**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"]],"caption":"UML Multiplicity Notation","headers":["Notation","Meaning","Example"]},"type":"table"},{"data":{"content":"**Common Multiplicity Patterns:**"},"type":"text"},{"data":{"items":["**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).*"],"title":{"icon":"ListIcon","text":"Multiplicity in Practice","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"icon":"AlertCircle","title":"Many-to-Many: The Design Trigger","content":"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?\"","variant":"warning"},"type":"callout"},{"data":{"code":"$7b","fileName":"MultiplicityExamples.java","showLineNumbers":true},"type":"code"}],"titleType":"number","titleNumber":4},{"id":"roles-and-names","title":"Roles and Association Names","content":[{"data":{"content":"Well-designed associations include **naming** and **role** information that clarifies the purpose of the relationship. This is especially important when:\n\n- A class has multiple associations to the same target class\n- The nature of the association isn't obvious from the class names\n- The same class participates in an association with itself (self-association)"},"type":"text"},{"data":{"content":"**Association Names**: Describe the nature of the relationship as a verb or verb phrase.\n\n```\nPerson ——— works for ——→ Company\nStudent ——— enrolls in ——→ Course\nAuthor ——— writes ——→ Book\n```\n\n**Role Names**: Describe what role each participating object plays in the association.\n\n```\nEmployee —————→ Employee\n ↑ ↑\n | |\n subordinate manager\n```"},"type":"text"},{"data":{"icon":"Lightbulb","title":"Self-Associations Require Roles","content":"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.","variant":"tip"},"type":"callout"},{"data":{"code":"$7c","fileName":"RolesExample.java","showLineNumbers":true},"type":"code"}],"titleType":"number","titleNumber":5},{"id":"pitfalls-antipatterns","title":"Common Pitfalls and Anti-Patterns","content":[{"data":{"content":"Association design is fraught with common mistakes. Here are the most frequent anti-patterns and how to avoid them:"},"type":"text"},{"data":{"items":["**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."],"title":{"icon":"XCircle","text":"Association Anti-Patterns","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"left":[{"data":{"code":"// ❌ ANTI-PATTERN: Exposed mutable list\npublic class Order {\n private List items;\n \n // BAD: External code can modify\n public List getItems() {\n return items; // Exposes internal state!\n }\n}\n\n// Usage that breaks encapsulation:\norder.getItems().clear(); // Oops!\norder.getItems().add(null); // Oops!","fileName":"BadAssociation.java","showLineNumbers":true},"type":"code"}],"right":[{"data":{"code":"// ✅ CORRECT: Encapsulated collection\npublic class Order {\n private List items;\n \n // Return unmodifiable view\n public List getItems() {\n return Collections.unmodifiableList(items);\n }\n \n // Control modifications via methods\n public void addItem(OrderItem item) {\n items.add(item);\n item.setOrder(this);\n }\n}","fileName":"GoodAssociation.java","showLineNumbers":true},"type":"code"}]},"type":"two-column"},{"data":{"icon":"AlertCircle","title":"The God Object Trap","content":"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.","variant":"error"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"best-practices","title":"Association Best Practices Checklist","content":[{"data":{"content":"Apply this checklist when designing associations to ensure your object relationships are well-formed:"},"type":"text"},{"data":{"type":"ordered","items":["**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."],"title":{"icon":"CheckCircle","text":"Association Design Checklist","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"titleType":"number","titleNumber":7},{"id":"summary","title":"Summary: Objects That Know Each Other","content":[{"data":{"content":"Association is the foundation of object relationships. Let's consolidate what we've learned:"},"type":"text"},{"data":{"type":"ordered","items":["**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."],"title":{"icon":"Target","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**Coming Up Next:**\n\nAssociation 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."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"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.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_9fa848ce7ece5e1f36dcd8a871c7e3d8","title":"Dependency — Objects That Use Each Other","order":1,"content":null,"isLocked":true},{"id":"seed_b046899ecfce047310075e003182c407","title":"Aggregation — Whole-Part with Independent Lifecycle","order":2,"content":null,"isLocked":true},{"id":"seed_43bec1bf740dc344b1c8285188dcc362","title":"Composition — Whole-Part with Dependent Lifecycle","order":3,"content":null,"isLocked":true}]}}