7a:T432,Relationships in software design serve multiple critical purposes that directly impact system quality: **1. Semantic Precision** Relationships encode meaning. The difference between "a Car *has* an Engine" (composition) versus "a Car *uses* a GasStation" (dependency) affects how we reason about the system, what invariants we can guarantee, and how the system evolves. **2. Lifecycle Management** Relationships determine object lifecycles. In composition, destroying the whole destroys the parts. In aggregation, parts outlive the container. Getting this wrong leads to memory leaks, dangling references, or inconsistent state. **3. Coupling Control** Different relationship types create different levels of coupling. Dependency is weaker than association, which is weaker than inheritance. Choosing the right relationship type directly affects maintainability and testability. **4. API Design** Relationships dictate your public interfaces. Should `Order.getCustomer()` return a full `Customer` object or just a customer ID? The relationship type guides this decision.7b:T505,// Association: Student and Course exist independently // A student can enroll in courses; courses can have students class Course { private courseName: string; private enrolledStudents: Student[] = []; constructor(courseName: string) { this.courseName = courseName; } enrollStudent(student: Student): void { this.enrolledStudents.push(student); // Note: We don't create the student - they exist independently } getEnrolledStudents(): Student[] { return [...this.enrolledStudents]; } } class Student { private studentId: string; private enrolledCourses: Course[] = []; constructor(studentId: string) { this.studentId = studentId; } enrollInCourse(course: Course): void { this.enrolledCourses.push(course); course.enrollStudent(this); } // Student continues to exist even if dropped from all courses dropAllCourses(): void { this.enrolledCourses = []; } } // Usage: Both objects have independent lifecycles const student = new Student("S001"); const course = new Course("Data Structures"); student.enrollInCourse(course); // Deleting the course doesn't delete the student // Deleting the student doesn't delete the course7c:T43b,// Association: Doctor and Patient exist independently public class Patient { private String patientId; private String name; private List treatingDoctors = new ArrayList<>(); public Patient(String patientId, String name) { this.patientId = patientId; this.name = name; } public void addDoctor(Doctor doctor) { treatingDoctors.add(doctor); } public List getTreatingDoctors() { return Collections.unmodifiableList(treatingDoctors); } } public class Doctor { private String doctorId; private String specialization; private List patients = new ArrayList<>(); public Doctor(String doctorId, String specialization) { this.doctorId = doctorId; this.specialization = specialization; } public void treatPatient(Patient patient) { patients.add(patient); patient.addDoctor(this); } // Doctor continues to exist even without patients public void retireFromPractice() { patients.clear(); } }7d:T5b6,// Aggregation: Playlist aggregates Songs // Songs exist independently and can belong to multiple playlists class Song { constructor( public readonly id: string, public readonly title: string, public readonly artist: string, public readonly durationSeconds: number ) {} } class Playlist { private name: string; private songs: Song[] = []; constructor(name: string) { this.name = name; } // Aggregation: we receive an existing song, we don't create it addSong(song: Song): void { if (!this.songs.find(s => s.id === song.id)) { this.songs.push(song); } } removeSong(songId: string): void { this.songs = this.songs.filter(s => s.id !== songId); // Note: Song still exists after removal from playlist } getTotalDuration(): number { return this.songs.reduce((sum, song) => sum + song.durationSeconds, 0); } } // Usage: Songs have independent lifecycles const song1 = new Song("1", "Bohemian Rhapsody", "Queen", 354); const song2 = new Song("2", "Stairway to Heaven", "Led Zeppelin", 482); const rockPlaylist = new Playlist("Classic Rock"); const favoritesPlaylist = new Playlist("My Favorites"); // Same song in multiple playlists (shared ownership) rockPlaylist.addSong(song1); favoritesPlaylist.addSong(song1); // Deleting playlist doesn't delete songs // Songs persist across playlist deletions7e:T524,// Aggregation: Department aggregates Employees // Employees exist independently and can move between departments public class Employee { private final String employeeId; private String name; private Department currentDepartment; public Employee(String employeeId, String name) { this.employeeId = employeeId; this.name = name; } public void setDepartment(Department dept) { this.currentDepartment = dept; } public String getEmployeeId() { return employeeId; } } public class Department { private String name; private List employees = new ArrayList<>(); public Department(String name) { this.name = name; } // Aggregation: Employee passed in, not created here public void addEmployee(Employee employee) { employees.add(employee); employee.setDepartment(this); } public void removeEmployee(Employee employee) { employees.remove(employee); employee.setDepartment(null); // Employee still exists after removal! } // Even if department is dissolved, employees continue to exist public void dissolve() { for (Employee emp : employees) { emp.setDepartment(null); } employees.clear(); } }7f:T614,// Composition: Order owns OrderItems exclusively // OrderItems cannot exist without their parent Order class OrderItem { constructor( public readonly productId: string, public readonly productName: string, public readonly quantity: number, public readonly unitPrice: number ) {} getSubtotal(): number { return this.quantity * this.unitPrice; } } class Order { private readonly orderId: string; private readonly items: OrderItem[] = []; private readonly createdAt: Date; constructor(orderId: string) { this.orderId = orderId; this.createdAt = new Date(); } // Composition: We CREATE the OrderItem here // It's not passed in from outside addItem(productId: string, name: string, qty: number, price: number): void { const item = new OrderItem(productId, name, qty, price); this.items.push(item); } getTotal(): number { return this.items.reduce((sum, item) => sum + item.getSubtotal(), 0); } getItems(): ReadonlyArray { return this.items; } // When order is cancelled/deleted, all items are gone // There's no separate "delete item and it still exists" operation } // Usage demonstrates exclusive ownership const order = new Order("ORD-001"); order.addItem("PROD-1", "Keyboard", 2, 49.99); order.addItem("PROD-2", "Mouse", 1, 29.99); // Items are PART OF the order // If order is deleted, items are deleted // Items cannot be "moved" to another order80:T52a,// Composition: House owns Rooms exclusively // Rooms cannot exist without their containing House public class Room { private final String name; private final double areaSqFt; private final RoomType type; // Package-private: only House can create rooms Room(String name, double areaSqFt, RoomType type) { this.name = name; this.areaSqFt = areaSqFt; this.type = type; } public String getName() { return name; } public double getAreaSqFt() { return areaSqFt; } } public class House { private final String address; private final List rooms = new ArrayList<>(); public House(String address) { this.address = address; } // Composition: House creates and owns the room public Room addRoom(String name, double area, RoomType type) { Room room = new Room(name, area, type); rooms.add(room); return room; } public double getTotalArea() { return rooms.stream() .mapToDouble(Room::getAreaSqFt) .sum(); } public List getRooms() { return Collections.unmodifiableList(rooms); } // When house is demolished, all rooms cease to exist // There's no concept of "moving a room to another house" }81:T604,// Dependency: ReportGenerator uses DateFormatter // No persistent reference - just uses it when needed interface DateFormatter { format(date: Date): string; } class ISODateFormatter implements DateFormatter { format(date: Date): string { return date.toISOString(); } } class HumanReadableDateFormatter implements DateFormatter { format(date: Date): string { return date.toLocaleDateString('en-US', { weekday: 'long', year: 'numeric', month: 'long', day: 'numeric' }); } } class ReportGenerator { // No field storing DateFormatter - that would be association // Dependency: DateFormatter is received as parameter generateReport(data: ReportData, formatter: DateFormatter): string { const formattedDate = formatter.format(new Date()); return `Report generated on: ${formattedDate} ${data.content}`; } // Another form of dependency: using a static method generateQuickReport(data: ReportData): string { // Depends on Date class const timestamp = new Date().getTime(); return `Quick Report [${timestamp}]: ${data.summary}`; } } // Dependency allows flexibility - different formatters can be used const generator = new ReportGenerator(); const data = { content: "Sales figures...", summary: "Q4 Report" }; const isoReport = generator.generateReport(data, new ISODateFormatter()); const readableReport = generator.generateReport(data, new HumanReadableDateFormatter());82:T4f5,// Dependency: OrderService uses EmailSender // Transient relationship - no field reference public interface EmailSender { void send(String to, String subject, String body); } public class SmtpEmailSender implements EmailSender { @Override public void send(String to, String subject, String body) { // SMTP implementation } } public class OrderService { // Note: No EmailSender field - pure dependency // Dependency via method parameter public void processOrder(Order order, EmailSender emailSender) { // Process the order... order.setStatus(OrderStatus.CONFIRMED); // Use the email sender (dependency) emailSender.send( order.getCustomerEmail(), "Order Confirmed", "Your order " + order.getId() + " has been confirmed." ); // EmailSender is not stored - relationship ends when method returns } // Dependency via local variable public void generateInvoice(Order order) { // Depends on InvoiceFormatter InvoiceFormatter formatter = InvoiceFormatterFactory.create(); String invoice = formatter.format(order); // formatter goes out of scope - no persistent relationship } }83:T6ba,// Inheritance: Different payment methods inherit from base abstract class PaymentMethod { protected readonly id: string; protected readonly createdAt: Date; constructor(id: string) { this.id = id; this.createdAt = new Date(); } abstract processPayment(amount: number): Promise; abstract validate(): boolean; // Shared behavior getPaymentMethodId(): string { return this.id; } } class CreditCard extends PaymentMethod { constructor( id: string, private cardNumber: string, private expiryMonth: number, private expiryYear: number, private cvv: string ) { super(id); } validate(): boolean { const now = new Date(); const expiry = new Date(this.expiryYear, this.expiryMonth - 1); return expiry > now && this.cardNumber.length === 16; } async processPayment(amount: number): Promise { // Credit card specific processing return { success: true, transactionId: `CC-${Date.now()}` }; } // Credit card specific method getMaskedNumber(): string { return `****-****-****-${this.cardNumber.slice(-4)}`; } } class BankTransfer extends PaymentMethod { constructor( id: string, private routingNumber: string, private accountNumber: string ) { super(id); } validate(): boolean { return this.routingNumber.length === 9; } async processPayment(amount: number): Promise { // Bank transfer specific processing return { success: true, transactionId: `BT-${Date.now()}` }; } }84:T67c,// Realization: Classes implement the Repository interface interface Repository { findById(id: ID): Promise; findAll(): Promise; save(entity: T): Promise; delete(id: ID): Promise; } // PostgreSQL implementation class PostgresUserRepository implements Repository { constructor(private pool: Pool) {} async findById(id: string): Promise { const result = await this.pool.query( 'SELECT * FROM users WHERE id = $1', [id] ); return result.rows[0] ?? null; } async findAll(): Promise { const result = await this.pool.query('SELECT * FROM users'); return result.rows; } async save(user: User): Promise { // PostgreSQL-specific save logic return user; } async delete(id: string): Promise { const result = await this.pool.query( 'DELETE FROM users WHERE id = $1', [id] ); return result.rowCount > 0; } } // In-memory implementation for testing class InMemoryUserRepository implements Repository { private users: Map = new Map(); async findById(id: string): Promise { return this.users.get(id) ?? null; } async findAll(): Promise { return Array.from(this.users.values()); } async save(user: User): Promise { this.users.set(user.id, user); return user; } async delete(id: string): Promise { return this.users.delete(id); } }72:{"json":{"id":"seed_9dfd1005e883e7ef3d5eea69f0a2d62a","slug":"defining-relationships","category":"System Design (LLD)","topic":"Defining Relationships","title":"Defining Relationships in Low-Level Design","description":"Master the art of defining relationships between entities in LLD. Learn relationship types, cardinality, multiplicity, navigability, and validation techniques to create robust, well-structured object models.","difficulty":"INTERMEDIATE","estimatedMinutes":60,"pages":[{"id":"seed_1355d84eff69ef67199bf34dd8cbd219","title":"Relationship Types Review","order":0,"content":[{"id":"opening-hook","title":"The Invisible Architecture of Software","content":[{"data":{"content":"In object-oriented design, classes are the nouns—but **relationships are the verbs that give your system meaning**. A perfectly designed class in isolation is useless; it's the connections between classes that enable behavior, enforce constraints, and ultimately determine whether your system is robust or fragile.\n\nConsider a banking system: a `Customer` class means nothing without its relationship to `Account`. An `Account` without connection to `Transaction` cannot track history. The relationships define not just structure, but the very semantics of what operations are possible and how data flows through your system."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will have a comprehensive understanding of all major relationship types in OOP—association, aggregation, composition, dependency, inheritance, and realization. You'll know when to use each, how they differ semantically, and how to represent them in code and UML.","variant":"info"},"type":"callout"}]},{"id":"why-relationships-matter","title":"Why Relationships Matter in LLD","content":[{"data":{"content":"$7a"},"type":"text"},{"data":{"icon":"AlertCircle","title":"The Cost of Wrong Relationships","content":"Misidentifying relationships is one of the most expensive design mistakes. Using inheritance when composition is appropriate leads to fragile base class problems. Using composition when aggregation is correct creates artificial lifecycle constraints. These mistakes compound as systems grow, becoming increasingly expensive to fix.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"association-relationship","title":"Association: The General Relationship","content":[{"data":{"content":"**Association** is the most general form of relationship between classes. It represents a structural connection where objects of one class are connected to objects of another class. Association implies that objects know about each other and can interact.\n\n**Key Characteristics:**\n- Both objects can exist independently\n- Neither object owns the other\n- The relationship can be temporary or permanent\n- Navigation can be unidirectional or bidirectional\n\n**Real-World Examples:**\n- A `Student` is associated with a `Course` (enrolled in)\n- A `Doctor` is associated with a `Patient` (treats)\n- An `Employee` is associated with a `Project` (works on)"},"type":"text"},{"data":{"fileName":"association-example","languages":[{"code":"$7b","label":"TypeScript","value":"typescript"},{"code":"$7c","label":"Java","value":"java"}]},"type":"code"},{"data":{"content":"**UML Representation:**\nAssociation is represented by a solid line connecting two classes. Role names and multiplicities can appear at each end."},"type":"text"}],"titleType":"number","titleNumber":2},{"id":"aggregation-relationship","title":"Aggregation: The 'Has-A' Relationship","content":[{"data":{"content":"**Aggregation** is a specialized form of association that represents a whole-part relationship where **parts can exist independently of the whole**. It's often called a \"has-a\" relationship with shared ownership.\n\n**Key Characteristics:**\n- Whole contains or aggregates parts\n- Parts have their own lifecycle\n- Parts can belong to multiple wholes simultaneously\n- Destroying the whole does NOT destroy the parts\n\n**Real-World Examples:**\n- A `Department` has `Employee`s (employees can move between departments)\n- A `Playlist` has `Song`s (songs exist in multiple playlists)\n- A `Team` has `Player`s (players can be traded)"},"type":"text"},{"data":{"fileName":"aggregation-example","languages":[{"code":"$7d","label":"TypeScript","value":"typescript"},{"code":"$7e","label":"Java","value":"java"}]},"type":"code"},{"data":{"icon":"Lightbulb","title":"UML Notation","content":"Aggregation is represented by a line with an **empty diamond** on the whole side. The diamond points to the container/whole, indicating 'this class aggregates that class.'","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"composition-relationship","title":"Composition: Strong Ownership","content":[{"data":{"content":"**Composition** is a strong form of aggregation where **parts cannot exist without the whole**. It represents exclusive ownership with coupled lifecycles.\n\n**Key Characteristics:**\n- Parts are created and destroyed with the whole\n- Parts cannot be shared between wholes\n- The whole is responsible for part lifecycle\n- Destroying the whole automatically destroys all parts\n\n**Real-World Examples:**\n- A `House` is composed of `Room`s (rooms don't exist outside a house)\n- An `Order` is composed of `OrderItem`s (items belong to one order)\n- A `Car` is composed of an `Engine` (engine is part of exactly one car)"},"type":"text"},{"data":{"fileName":"composition-example","languages":[{"code":"$7f","label":"TypeScript","value":"typescript"},{"code":"$80","label":"Java","value":"java"}]},"type":"code"},{"data":{"icon":"Info","title":"UML Notation","content":"Composition is represented by a line with a **filled diamond** on the whole side. The filled diamond indicates strong ownership—the whole controls the lifecycle of the parts.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"dependency-relationship","title":"Dependency: The 'Uses-A' Relationship","content":[{"data":{"content":"**Dependency** is the weakest form of relationship. It exists when one class uses another class without maintaining a persistent reference. The relationship is transient—it exists only during method execution.\n\n**Key Characteristics:**\n- No persistent reference between classes\n- Used class appears as method parameter, local variable, or return type\n- Changes to the used class may affect the using class\n- Represents a \"uses\" semantic\n\n**Real-World Examples:**\n- A `ReportGenerator` depends on `DateFormatter` (uses it to format dates)\n- An `OrderService` depends on `EmailSender` (uses it to send confirmations)\n- A `PaymentProcessor` depends on `CurrencyConverter` (uses it for conversion)"},"type":"text"},{"data":{"fileName":"dependency-example","languages":[{"code":"$81","label":"TypeScript","value":"typescript"},{"code":"$82","label":"Java","value":"java"}]},"type":"code"},{"data":{"icon":"Lightbulb","title":"UML Notation","content":"Dependency is represented by a **dashed arrow** pointing from the dependent class to the class it depends on. The arrow indicates 'this class depends on that class.'","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"inheritance-relationship","title":"Inheritance: The 'Is-A' Relationship","content":[{"data":{"content":"**Inheritance** represents a generalization/specialization relationship. A subclass \"is-a\" type of its superclass, inheriting its structure and behavior while adding or overriding capabilities.\n\n**Key Characteristics:**\n- Represents an \"is-a\" semantic (a Dog is-a Animal)\n- Subclass inherits fields and methods from superclass\n- Subclass can override behavior\n- Creates the strongest coupling between classes\n- Enables polymorphism\n\n**When to Use Inheritance:**\n- True is-a relationship (not just code reuse)\n- Subclass is a proper subtype (Liskov Substitution Principle)\n- Shared behavior is fundamental, not incidental"},"type":"text"},{"data":{"fileName":"inheritance-example","languages":[{"code":"$83","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"icon":"AlertCircle","title":"Inheritance Pitfalls","content":"Inheritance creates the tightest coupling. Favor composition over inheritance when possible. Use inheritance only for true is-a relationships where substitutability is guaranteed. Overusing inheritance leads to fragile base class problems and rigid hierarchies.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"realization-relationship","title":"Realization: Implementing Interfaces","content":[{"data":{"content":"**Realization** (or Implementation) represents the relationship between an interface and a class that implements it. The class agrees to fulfill the contract defined by the interface.\n\n**Key Characteristics:**\n- Interface defines the contract (what)\n- Implementing class provides the behavior (how)\n- Enables loose coupling through abstraction\n- Supports multiple interface implementation\n- Foundation for dependency inversion"},"type":"text"},{"data":{"fileName":"realization-example","languages":[{"code":"$84","label":"TypeScript","value":"typescript"}]},"type":"code"}],"titleType":"number","titleNumber":7},{"id":"summary","title":"Summary: Relationship Types at a Glance","content":[{"data":{"rows":[["Association","Medium","Independent","Solid line","Student ↔ Course"],["Aggregation","Medium","Independent","Empty diamond","Playlist ◇→ Song"],["Composition","Strong","Coupled","Filled diamond","Order ◆→ OrderItem"],["Dependency","Weak","Transient","Dashed arrow","Service ⇢ Helper"],["Inheritance","Strongest","Coupled","Hollow arrow","CreditCard ▷ PaymentMethod"],["Realization","Medium","Independent","Dashed hollow arrow","Class ⇢▷ Interface"]],"caption":"Comparison of Relationship Types","headers":["Relationship","Coupling","Lifecycle","UML Symbol","Example"]},"type":"table"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now have a comprehensive understanding of all major relationship types in OOP. In the next page, we'll dive deep into cardinality and multiplicity—how to specify how many objects participate in each relationship.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_5bce7498dcc0e949a1f347ab57d04daa","title":"Cardinality and Multiplicity","order":1,"content":null,"isLocked":true},{"id":"seed_c9c8420bf644f91848bcf3d99e20dfee","title":"Navigability","order":2,"content":null,"isLocked":true},{"id":"seed_a1ef0bad0f86cfe15c753037d9028ae6","title":"Relationship Validation","order":3,"content":null,"isLocked":true}]}}