System Design (LLD)HAS-A vs IS-A Relationships

HAS-A vs IS-A Relationships

LevelIntermediate

Duration60 mins

TopicHAS-A vs IS-A Relationships

2 / 4

HAS-A — The Composition Relationship

Building Through Assembly

If IS-A represents inheritance—the taxonomic classification of types—then HAS-A represents composition: building complex objects by containing simpler objects. This is the relationship that models ownership, containment, and assembly.

Where IS-A says "this type is a specialized version of that type," HAS-A says "this type contains that type as a component." The distinction is profound: inheritance creates type identity, while composition creates object structure.

Understanding HAS-A is essential because it offers a fundamentally different—and often superior—approach to code reuse and object construction. While inheritance ties you to a fixed type hierarchy, composition gives you the freedom to assemble behavior at runtime from interchangeable parts.

What You Will Learn

By the end of this page, you will understand HAS-A as a structural relationship of containment, distinguish between its strong form (composition) and weak form (aggregation), and recognize when HAS-A is the appropriate choice for your design.

Defining HAS-A Precisely

The HAS-A relationship signifies that one object contains another object as a part, member, or component. When we say "class A HAS-A class B," we mean that instances of A hold references to instances of B, and A delegates some of its responsibilities to B.

This is fundamentally different from inheritance:

IS-A (Inheritance): Dog IS-A Animal → Dog is a type of Animal
HAS-A (Composition): Car HAS-A Engine → Car contains an Engine

The Containment Model:

In HAS-A, the containing object (the "whole") manages one or more contained objects (the "parts"). The whole:

Creates or acquires the parts
Delegates operations to the parts
Controls the lifecycle of the parts (in composition)
Coordinates between multiple parts

The parts do their specialized work without knowing about the whole—they're reusable components that can serve different containers.

has-a-basic-example.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
// Car HAS-A Engine: The car contains an engine
public class Engine {
    private final int horsepower;
    private boolean running = false;
    
    public Engine(int horsepower) {
        this.horsepower = horsepower;
    }
    
    public void start() {
        running = true;
        System.out.println("Engine started: " + horsepower + " HP");
    }
    
    public void stop() {
        running = false;
        System.out.println("Engine stopped");
    }
    
    public int getHorsepower() {
        return horsepower;
    }
    
    public boolean isRunning() {
        return running;
    }
}
 
public class Car {
    // HAS-A relationship: Car contains an Engine
    private final Engine engine;
    private final String model;
    
    public Car(String model, Engine engine) {
        this.model = model;
        this.engine = engine;  // Car HAS-A Engine
    }
    
    public void start() {
        System.out.println("Starting " + model);
        engine.start();  // Delegation: Car delegates to Engine
    }
    
    public void stop() {
        engine.stop();
        System.out.println(model + " stopped");
    }
    
    public int getPower() {
        return engine.getHorsepower();  // Expose Engine functionality
    }
}
 
// Usage
Engine v8 = new Engine(400);
Car mustang = new Car("Ford Mustang", v8);
mustang.start();  // Ford Mustang starting... Engine started: 400 HP

Key Characteristics of HAS-A:

Containment: The whole contains references to parts as instance fields
Delegation: The whole forwards requests to parts rather than implementing everything itself
Encapsulation: Parts are typically private; the whole controls access to them
Independence: Parts can exist and be tested independently of the whole
Replaceability: Parts can potentially be swapped at construction time (or even at runtime)

Composition vs Aggregation

The HAS-A relationship has two flavors with different lifecycle semantics:

Composition (Strong HAS-A):

The contained object's lifecycle is bound to the container. When the container is destroyed, so is the contained object. The part cannot exist independently of the whole.

Examples:

A House HAS Rooms (destroy the house, the rooms cease to exist as rooms)
An Order HAS OrderLines (order lines have no meaning without their order)
A Brain HAS Neurons (neurons are part of that specific brain)

Aggregation (Weak HAS-A):

The contained object exists independently of the container. The container merely uses or references the contained object, but doesn't control its lifecycle.

Examples:

A Department HAS Employees (employees exist independently; they can move departments)
A Playlist HAS Songs (songs exist independently of any playlist)
A University HAS Professors (professors have their own existence)

Composition vs Aggregation Comparison
Aspect	Composition (Strong)	Aggregation (Weak)
Lifecycle	Part dies with whole	Part survives whole
Ownership	Exclusive ownership	Shared or borrowed reference
Creation	Whole creates parts	Parts created externally
Sharing	Parts not shared	Parts may be shared
Notation (UML)	Filled diamond	Empty diamond
Code pattern	Create in constructor	Accept in constructor/setter

composition-vs-aggregation.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
// COMPOSITION: Room cannot exist without House
public class House {
    private final List<Room> rooms;  // House OWNS rooms
    
    public House(int numberOfRooms) {
        // House CREATES the rooms - it controls their lifecycle
        this.rooms = new ArrayList<>();
        for (int i = 0; i < numberOfRooms; i++) {
            rooms.add(new Room(30 + i * 5, this));  // Rooms belong to THIS house
        }
    }
    
    public void demolish() {
        // When house is demolished, rooms are destroyed too
        rooms.clear();  // Rooms cease to exist as meaningful entities
    }
}
 
// AGGREGATION: Employees exist independently of Department
public class Department {
    private final String name;
    private final List<Employee> employees;  // Department REFERENCES employees
    
    public Department(String name) {
        this.name = name;
        this.employees = new ArrayList<>();
    }
    
    public void addEmployee(Employee emp) {
        // Employee was created elsewhere and passed in
        employees.add(emp);
    }
    
    public void removeEmployee(Employee emp) {
        employees.remove(emp);
        // Employee continues to exist! They just left this department.
    }
    
    public void close() {
        employees.clear();  // Employees are removed but NOT destroyed
        // They can join other departments
    }
}
 
// The distinction matters for resource management
public class ResourceExample {
    public void demonstrateDifference() {
        // Composition: resources managed internally
        var house = new House(5);  // House creates rooms
        // When house goes out of scope, rooms are garbage collected together
        
        // Aggregation: resources managed externally
        var emp1 = new Employee("Alice");  // Employee exists first
        var emp2 = new Employee("Bob");
        
        var engineering = new Department("Engineering");
        engineering.addEmployee(emp1);  // Alice joins Engineering
        engineering.addEmployee(emp2);  // Bob joins Engineering
        
        var sales = new Department("Sales");
        sales.addEmployee(emp1);  // Alice also in Sales! (shared reference)
        
        engineering.close();  // Alice and Bob still exist
        // They can continue in Sales or join new departments
    }
}

When Each Form Applies

Use composition when parts are intrinsically part of the whole and have no meaning outside it (document paragraphs, order items, game character body parts). Use aggregation when parts are independent entities that happen to be associated with the whole (students in a course, books in a library, employees in a team).

Delegation — The Mechanism of HAS-A

While HAS-A establishes the containment structure, delegation is the mechanism that makes it useful. Delegation means forwarding method calls from the containing object to the contained object.

Why Delegation Matters:

Without delegation, contained objects would just be passive data. Delegation transforms HAS-A from mere containment into behavior sharing—the container exposes capabilities of its parts without exposing the parts themselves.

Types of Delegation:

Full Forwarding: The container simply calls the component and returns its result
Partial Forwarding: The container adds logic before/after calling the component
Selective Exposure: The container only exposes some component methods
Transformation: The container transforms component results before returning

delegation-patterns.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
public class Logger {
    public void log(String message) {
        System.out.println("[LOG] " + message);
    }
    
    public void logError(String message) {
        System.err.println("[ERROR] " + message);
    }
    
    public void logWithTimestamp(String message) {
        System.out.println("[" + Instant.now() + "] " + message);
    }
}
 
public class PaymentProcessor {
    private final PaymentGateway gateway;
    private final Logger logger;  // HAS-A Logger
    
    public PaymentProcessor(PaymentGateway gateway, Logger logger) {
        this.gateway = gateway;
        this.logger = logger;
    }
    
    // Full Forwarding: just call the component method
    public void log(String message) {
        logger.log(message);  // Straight forwarding
    }
    
    // Partial Forwarding: add logic before/after
    public PaymentResult processPayment(Payment payment) {
        logger.log("Processing payment: " + payment.getId());
        
        var result = gateway.process(payment);  // Delegate to gateway
        
        if (result.isSuccess()) {
            logger.log("Payment successful");
        } else {
            logger.logError("Payment failed: " + result.getError());
        }
        
        return result;
    }
    
    // Selective Exposure: only expose what's needed
    // Notice we DON'T expose logWithTimestamp() - it's not relevant
    // for PaymentProcessor's clients
    
    // Transformation: modify component's output
    public String getProcessingLog(Payment payment) {
        // Gateway returns raw events, we transform to readable format
        List<Event> events = gateway.getEventsFor(payment.getId());
        return events.stream()
            .map(e -> e.getTimestamp() + ": " + e.getDescription())
            .collect(Collectors.joining("
"));
    }
}

Delegation vs Inheritance for Behavior:

Inheritance automatically gives the child all parent behaviors. Delegation requires explicit forwarding for each behavior you want to expose. This seems like more work, but it's actually an advantage:

Explicit control: You choose what to expose instead of inheriting everything
Flexibility: You can modify, filter, or transform delegated behavior
Multiple sources: You can delegate to multiple objects (unlike single inheritance)
Runtime changes: Delegates can be swapped at runtime

The Wrapper Pattern

When you compose an object mainly to add behavior while delegating most methods unchanged, you're implementing the Wrapper (Decorator) pattern. The Decorator extends functionality by composition rather than inheritance, gaining flexibility at the cost of explicit delegation code.

HAS-A Enables Runtime Flexibility

One of HAS-A's greatest strengths over IS-A is runtime flexibility. While inheritance relationships are fixed at compile time, composition relationships can be configured—even changed—at runtime.

Static vs Dynamic Behavior:

With inheritance:

class Dog extends Animal — A Dog is always an Animal, forever
The relationship is frozen in the class definition
Every Dog instance has the same parent behavior

With composition:

A Robot HAS-A MovementStrategy — The strategy can be injected
Different robots can have different movement strategies
The same robot can change strategies at runtime

runtime-flexibility.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
// Strategy interface - defines what we can swap
public interface CompressionStrategy {
    byte[] compress(byte[] data);
    byte[] decompress(byte[] data);
    String getName();
}
 
// Different strategies - can be selected at runtime
public class ZipCompression implements CompressionStrategy {
    @Override
    public byte[] compress(byte[] data) { /* ZIP implementation */ }
    @Override
    public byte[] decompress(byte[] data) { /* ZIP implementation */ }
    @Override
    public String getName() { return "ZIP"; }
}
 
public class GzipCompression implements CompressionStrategy {
    @Override
    public byte[] compress(byte[] data) { /* GZIP implementation */ }
    @Override
    public byte[] decompress(byte[] data) { /* GZIP implementation */ }
    @Override
    public String getName() { return "GZIP"; }
}
 
public class LZ4Compression implements CompressionStrategy {
    @Override
    public byte[] compress(byte[] data) { /* LZ4 implementation */ }
    @Override
    public byte[] decompress(byte[] data) { /* LZ4 implementation */ }
    @Override
    public String getName() { return "LZ4"; }
}
 
// FileArchiver HAS-A CompressionStrategy (via composition)
public class FileArchiver {
    private CompressionStrategy strategy;  // Can be changed!
    
    public FileArchiver(CompressionStrategy strategy) {
        this.strategy = strategy;
    }
    
    // Runtime strategy switching!
    public void setStrategy(CompressionStrategy strategy) {
        System.out.println("Switching from " + this.strategy.getName() 
            + " to " + strategy.getName());
        this.strategy = strategy;
    }
    
    public void archive(List<File> files, Path destination) {
        System.out.println("Archiving with " + strategy.getName());
        for (File file : files) {
            byte[] compressed = strategy.compress(readFile(file));
            writeToArchive(destination, file.getName(), compressed);
        }
    }
    
    public void extract(Path archive, Path destination) {
        // Uses current strategy for decompression
        // ...
    }
}
 
// Usage: behavior changes at runtime!
FileArchiver archiver = new FileArchiver(new ZipCompression());
archiver.archive(files, archive1);  // Uses ZIP
 
archiver.setStrategy(new LZ4Compression());  // Switch to faster algorithm
archiver.archive(files, archive2);  // Uses LZ4
 
// Strategy can be chosen based on runtime conditions
CompressionStrategy strategy = fileSize > LARGE_THRESHOLD 
    ? new LZ4Compression()   // Fast for large files
    : new GzipCompression(); // Better ratio for small files
archiver.setStrategy(strategy);

Implications of Runtime Flexibility:

Configuration over hardcoding: Behavior can be configured at startup via dependency injection
Adaptation: Objects can adapt to changing conditions by swapping components
Testing: Test doubles can be injected without subclassing
A/B testing: Different implementations can be deployed to different users
Progressive enhancement: Start simple, swap in sophisticated components later

The Power of Dependency Injection

Dependency injection leverages HAS-A to its fullest. By passing dependencies into constructors (rather than creating them internally), you gain control over what implementations are used—enabling testing with mocks, configuration-driven behavior, and clean separation of concerns.

Multiple HAS-A Relationships

Unlike inheritance (where most languages allow only single inheritance), composition has no such limitation. An object can have as many components as needed—each providing different capabilities.

Building Complex Objects:

Real-world objects are complex assemblies of many parts. A car has an engine, transmission, chassis, wheels, electronics, etc. Each component is a HAS-A relationship, and together they form the complete car.

Similarly, software objects often need multiple capabilities:

A WebApplication HAS-A Router, Database, Cache, Logger, AuthService, etc.
A Game HAS-A Renderer, PhysicsEngine, AudioSystem, InputHandler, etc.
A TradingBot HAS-A MarketDataFeed, OrderExecutor, RiskManager, Logger, etc.

multiple-has-a.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
// A complex object built from multiple components
public class SmartHome {
    // Multiple HAS-A relationships
    private final SecuritySystem security;
    private final ClimateControl climate;
    private final LightingSystem lighting;
    private final EntertainmentSystem entertainment;
    private final EnergyMonitor energy;
    private final List<Sensor> sensors;
    private final NotificationService notifications;
    
    // Constructor injection of all components
    public SmartHome(
            SecuritySystem security,
            ClimateControl climate,
            LightingSystem lighting,
            EntertainmentSystem entertainment,
            EnergyMonitor energy,
            List<Sensor> sensors,
            NotificationService notifications) {
        this.security = security;
        this.climate = climate;
        this.lighting = lighting;
        this.entertainment = entertainment;
        this.energy = energy;
        this.sensors = sensors;
        this.notifications = notifications;
    }
    
    // Coordinate multiple components for complex behaviors
    public void setAwayMode() {
        security.arm();
        climate.setEcoMode();
        lighting.turnOffAll();
        entertainment.turnOff();
        notifications.send("Home set to away mode");
    }
    
    public void setHomeMode() {
        security.disarm();
        climate.setComfortMode();
        lighting.setWelcomeScene();
    }
    
    public void handleMotionDetected(Sensor sensor) {
        if (security.isArmed()) {
            security.alertMotion(sensor.getLocation());
            notifications.sendUrgent("Motion detected: " + sensor.getLocation());
            lighting.turnOnAt(sensor.getLocation());  // Illuminate the area
        }
    }
    
    public EnergyReport getDailyEnergyReport() {
        return new EnergyReport(
            energy.getTodayUsage(),
            climate.getEnergyUsage(),
            lighting.getEnergyUsage(),
            entertainment.getEnergyUsage()
        );
    }
    
    // Each component can be accessed individually if needed
    public SecuritySystem getSecurity() { return security; }
    public ClimateControl getClimate() { return climate; }
    // ... etc
}
 
// This would be IMPOSSIBLE with inheritance
// You can't write: class SmartHome extends SecuritySystem, ClimateControl, ...

The Coordinator Role:

When an object has many components, it often plays a coordinator role—orchestrating the components to achieve higher-level behaviors. The coordinator:

Knows about all components and how they interact
Implements workflows that span multiple components
Maintains overall consistency and invariants
Exposes a unified interface to clients

This is the natural pattern for complex systems: decompose into specialized components, then compose them with a coordinator that manages their interactions.

Composition vs Interface Implementation

An object can implement multiple interfaces, which might seem similar to having multiple components. But interfaces only provide TYPE relationships, not behavior. Composition with delegation provides actual reusable BEHAVIOR from each component—the component does the work, not just declares capabilities.

When HAS-A Is The Right Choice

Now that we understand HAS-A, when should we prefer it over IS-A (inheritance)? Here are the key indicators:

Choose HAS-A When:

HAS-A Is Appropriate When...

•The relationship is containment, not identity — "Car contains Engine" not "Car is a kind of Engine"
•You need runtime flexibility — Components can be swapped or configured differently for different instances
•Multiple capabilities are needed — You need behavior from several sources (interfaces alone won't provide the implementation)
•The component is reusable across contexts — The same Logger can be used by many different classes
•You want encapsulation — Internal components are hidden; clients interact only with the containing class
•You need to test in isolation — Mock components can be injected for testing
•The relationship might change — Today's component might be replaced with a better one tomorrow
•You're integrating third-party code — You can't inherit from sealed/final classes, but you can contain them

The Litmus Test:

Ask yourself: "Would it make sense to substitute the whole for the part?"

If yes (a Dog can be used where Animal is expected) → IS-A might apply
If no (a Car cannot be used where Engine is expected) → HAS-A applies

Also ask: "Does the whole need to be a specialized version of the part?"

If yes → IS-A relationship
If no, just needs the part's functionality → HAS-A relationship

Good HAS-A Examples

•Car HAS-A Engine
•Department HAS-A List<Employee>
•Order HAS-A List<OrderLine>
•Game HAS-A Renderer
•Controller HAS-A Service
•EmailSender HAS-A SMTPClient

Bad HAS-A (Should Be IS-A)

•Dog HAS-A Animal traits ❌
•PdfDocument HAS-A Document ❌
•SavingsAccount HAS-A BankAccount ❌
•Manager HAS-A Employee ❌
•Square HAS-A Rectangle ❌
•HttpException HAS-A Exception ❌

Summary: The HAS-A Relationship

We've developed a thorough understanding of HAS-A—the composition relationship that models containment and assembly. Let's consolidate the key insights:

Key Takeaways

•HAS-A means containment — One object contains another as a component, not as a type classification
•Composition vs Aggregation — Composition implies lifecycle ownership; aggregation implies shared references
•Delegation is the mechanism — The container forwards calls to components to expose their behavior
•Runtime flexibility — Components can be swapped, configured, or changed at runtime
•Multiple components are natural — Unlike single inheritance, you can compose any number of components
•Encapsulation preserved — Components can be hidden, with only selected behavior exposed
•Use when relationship is containment, not identity — "Contains" not "is a kind of"

What's Next:

Now that we understand both IS-A (inheritance) and HAS-A (composition), the crucial question becomes: how do we choose between them in practice? The next page provides a systematic framework for testing which relationship applies to any given design scenario—helping you avoid the common mistakes that lead to fragile hierarchies.

Page Complete

You now understand HAS-A as a relationship of containment and assembly, powered by delegation, offering runtime flexibility and enabling complex objects built from multiple components. Next, we'll learn how to systematically test which relationship type applies.

2 / 4

Loading learning content...

System Design (LLD)HAS-A vs IS-A Relationships

HAS-A vs IS-A Relationships

LevelIntermediate

Duration60 mins

TopicHAS-A vs IS-A Relationships

2 / 4

HAS-A — The Composition Relationship

Building Through Assembly

What You Will Learn

Defining HAS-A Precisely

This is fundamentally different from inheritance:

IS-A (Inheritance): Dog IS-A Animal → Dog is a type of Animal
HAS-A (Composition): Car HAS-A Engine → Car contains an Engine

The Containment Model:

In HAS-A, the containing object (the "whole") manages one or more contained objects (the "parts"). The whole:

Creates or acquires the parts
Delegates operations to the parts
Controls the lifecycle of the parts (in composition)
Coordinates between multiple parts

The parts do their specialized work without knowing about the whole—they're reusable components that can serve different containers.

has-a-basic-example.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
// Car HAS-A Engine: The car contains an engine
public class Engine {
    private final int horsepower;
    private boolean running = false;
    
    public Engine(int horsepower) {
        this.horsepower = horsepower;
    }
    
    public void start() {
        running = true;
        System.out.println("Engine started: " + horsepower + " HP");
    }
    
    public void stop() {
        running = false;
        System.out.println("Engine stopped");
    }
    
    public int getHorsepower() {
        return horsepower;
    }
    
    public boolean isRunning() {
        return running;
    }
}
 
public class Car {
    // HAS-A relationship: Car contains an Engine
    private final Engine engine;
    private final String model;
    
    public Car(String model, Engine engine) {
        this.model = model;
        this.engine = engine;  // Car HAS-A Engine
    }
    
    public void start() {
        System.out.println("Starting " + model);
        engine.start();  // Delegation: Car delegates to Engine
    }
    
    public void stop() {
        engine.stop();
        System.out.println(model + " stopped");
    }
    
    public int getPower() {
        return engine.getHorsepower();  // Expose Engine functionality
    }
}
 
// Usage
Engine v8 = new Engine(400);
Car mustang = new Car("Ford Mustang", v8);
mustang.start();  // Ford Mustang starting... Engine started: 400 HP

Key Characteristics of HAS-A:

Containment: The whole contains references to parts as instance fields
Delegation: The whole forwards requests to parts rather than implementing everything itself
Encapsulation: Parts are typically private; the whole controls access to them
Independence: Parts can exist and be tested independently of the whole
Replaceability: Parts can potentially be swapped at construction time (or even at runtime)

Composition vs Aggregation

The HAS-A relationship has two flavors with different lifecycle semantics:

Composition (Strong HAS-A):

The contained object's lifecycle is bound to the container. When the container is destroyed, so is the contained object. The part cannot exist independently of the whole.

Examples:

A House HAS Rooms (destroy the house, the rooms cease to exist as rooms)
An Order HAS OrderLines (order lines have no meaning without their order)
A Brain HAS Neurons (neurons are part of that specific brain)

Aggregation (Weak HAS-A):

The contained object exists independently of the container. The container merely uses or references the contained object, but doesn't control its lifecycle.

Examples:

A Department HAS Employees (employees exist independently; they can move departments)
A Playlist HAS Songs (songs exist independently of any playlist)
A University HAS Professors (professors have their own existence)

Composition vs Aggregation Comparison
Aspect	Composition (Strong)	Aggregation (Weak)
Lifecycle	Part dies with whole	Part survives whole
Ownership	Exclusive ownership	Shared or borrowed reference
Creation	Whole creates parts	Parts created externally
Sharing	Parts not shared	Parts may be shared
Notation (UML)	Filled diamond	Empty diamond
Code pattern	Create in constructor	Accept in constructor/setter

composition-vs-aggregation.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
// COMPOSITION: Room cannot exist without House
public class House {
    private final List<Room> rooms;  // House OWNS rooms
    
    public House(int numberOfRooms) {
        // House CREATES the rooms - it controls their lifecycle
        this.rooms = new ArrayList<>();
        for (int i = 0; i < numberOfRooms; i++) {
            rooms.add(new Room(30 + i * 5, this));  // Rooms belong to THIS house
        }
    }
    
    public void demolish() {
        // When house is demolished, rooms are destroyed too
        rooms.clear();  // Rooms cease to exist as meaningful entities
    }
}
 
// AGGREGATION: Employees exist independently of Department
public class Department {
    private final String name;
    private final List<Employee> employees;  // Department REFERENCES employees
    
    public Department(String name) {
        this.name = name;
        this.employees = new ArrayList<>();
    }
    
    public void addEmployee(Employee emp) {
        // Employee was created elsewhere and passed in
        employees.add(emp);
    }
    
    public void removeEmployee(Employee emp) {
        employees.remove(emp);
        // Employee continues to exist! They just left this department.
    }
    
    public void close() {
        employees.clear();  // Employees are removed but NOT destroyed
        // They can join other departments
    }
}
 
// The distinction matters for resource management
public class ResourceExample {
    public void demonstrateDifference() {
        // Composition: resources managed internally
        var house = new House(5);  // House creates rooms
        // When house goes out of scope, rooms are garbage collected together
        
        // Aggregation: resources managed externally
        var emp1 = new Employee("Alice");  // Employee exists first
        var emp2 = new Employee("Bob");
        
        var engineering = new Department("Engineering");
        engineering.addEmployee(emp1);  // Alice joins Engineering
        engineering.addEmployee(emp2);  // Bob joins Engineering
        
        var sales = new Department("Sales");
        sales.addEmployee(emp1);  // Alice also in Sales! (shared reference)
        
        engineering.close();  // Alice and Bob still exist
        // They can continue in Sales or join new departments
    }
}

When Each Form Applies

Delegation — The Mechanism of HAS-A

While HAS-A establishes the containment structure, delegation is the mechanism that makes it useful. Delegation means forwarding method calls from the containing object to the contained object.

Why Delegation Matters:

Types of Delegation:

Full Forwarding: The container simply calls the component and returns its result
Partial Forwarding: The container adds logic before/after calling the component
Selective Exposure: The container only exposes some component methods
Transformation: The container transforms component results before returning

delegation-patterns.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
public class Logger {
    public void log(String message) {
        System.out.println("[LOG] " + message);
    }
    
    public void logError(String message) {
        System.err.println("[ERROR] " + message);
    }
    
    public void logWithTimestamp(String message) {
        System.out.println("[" + Instant.now() + "] " + message);
    }
}
 
public class PaymentProcessor {
    private final PaymentGateway gateway;
    private final Logger logger;  // HAS-A Logger
    
    public PaymentProcessor(PaymentGateway gateway, Logger logger) {
        this.gateway = gateway;
        this.logger = logger;
    }
    
    // Full Forwarding: just call the component method
    public void log(String message) {
        logger.log(message);  // Straight forwarding
    }
    
    // Partial Forwarding: add logic before/after
    public PaymentResult processPayment(Payment payment) {
        logger.log("Processing payment: " + payment.getId());
        
        var result = gateway.process(payment);  // Delegate to gateway
        
        if (result.isSuccess()) {
            logger.log("Payment successful");
        } else {
            logger.logError("Payment failed: " + result.getError());
        }
        
        return result;
    }
    
    // Selective Exposure: only expose what's needed
    // Notice we DON'T expose logWithTimestamp() - it's not relevant
    // for PaymentProcessor's clients
    
    // Transformation: modify component's output
    public String getProcessingLog(Payment payment) {
        // Gateway returns raw events, we transform to readable format
        List<Event> events = gateway.getEventsFor(payment.getId());
        return events.stream()
            .map(e -> e.getTimestamp() + ": " + e.getDescription())
            .collect(Collectors.joining("
"));
    }
}

Delegation vs Inheritance for Behavior:

Explicit control: You choose what to expose instead of inheriting everything
Flexibility: You can modify, filter, or transform delegated behavior
Multiple sources: You can delegate to multiple objects (unlike single inheritance)
Runtime changes: Delegates can be swapped at runtime

The Wrapper Pattern

HAS-A Enables Runtime Flexibility

Static vs Dynamic Behavior:

With inheritance:

class Dog extends Animal — A Dog is always an Animal, forever
The relationship is frozen in the class definition
Every Dog instance has the same parent behavior

With composition:

A Robot HAS-A MovementStrategy — The strategy can be injected
Different robots can have different movement strategies
The same robot can change strategies at runtime

runtime-flexibility.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
// Strategy interface - defines what we can swap
public interface CompressionStrategy {
    byte[] compress(byte[] data);
    byte[] decompress(byte[] data);
    String getName();
}
 
// Different strategies - can be selected at runtime
public class ZipCompression implements CompressionStrategy {
    @Override
    public byte[] compress(byte[] data) { /* ZIP implementation */ }
    @Override
    public byte[] decompress(byte[] data) { /* ZIP implementation */ }
    @Override
    public String getName() { return "ZIP"; }
}
 
public class GzipCompression implements CompressionStrategy {
    @Override
    public byte[] compress(byte[] data) { /* GZIP implementation */ }
    @Override
    public byte[] decompress(byte[] data) { /* GZIP implementation */ }
    @Override
    public String getName() { return "GZIP"; }
}
 
public class LZ4Compression implements CompressionStrategy {
    @Override
    public byte[] compress(byte[] data) { /* LZ4 implementation */ }
    @Override
    public byte[] decompress(byte[] data) { /* LZ4 implementation */ }
    @Override
    public String getName() { return "LZ4"; }
}
 
// FileArchiver HAS-A CompressionStrategy (via composition)
public class FileArchiver {
    private CompressionStrategy strategy;  // Can be changed!
    
    public FileArchiver(CompressionStrategy strategy) {
        this.strategy = strategy;
    }
    
    // Runtime strategy switching!
    public void setStrategy(CompressionStrategy strategy) {
        System.out.println("Switching from " + this.strategy.getName() 
            + " to " + strategy.getName());
        this.strategy = strategy;
    }
    
    public void archive(List<File> files, Path destination) {
        System.out.println("Archiving with " + strategy.getName());
        for (File file : files) {
            byte[] compressed = strategy.compress(readFile(file));
            writeToArchive(destination, file.getName(), compressed);
        }
    }
    
    public void extract(Path archive, Path destination) {
        // Uses current strategy for decompression
        // ...
    }
}
 
// Usage: behavior changes at runtime!
FileArchiver archiver = new FileArchiver(new ZipCompression());
archiver.archive(files, archive1);  // Uses ZIP
 
archiver.setStrategy(new LZ4Compression());  // Switch to faster algorithm
archiver.archive(files, archive2);  // Uses LZ4
 
// Strategy can be chosen based on runtime conditions
CompressionStrategy strategy = fileSize > LARGE_THRESHOLD 
    ? new LZ4Compression()   // Fast for large files
    : new GzipCompression(); // Better ratio for small files
archiver.setStrategy(strategy);

Implications of Runtime Flexibility:

Configuration over hardcoding: Behavior can be configured at startup via dependency injection
Adaptation: Objects can adapt to changing conditions by swapping components
Testing: Test doubles can be injected without subclassing
A/B testing: Different implementations can be deployed to different users
Progressive enhancement: Start simple, swap in sophisticated components later

The Power of Dependency Injection

Multiple HAS-A Relationships

Unlike inheritance (where most languages allow only single inheritance), composition has no such limitation. An object can have as many components as needed—each providing different capabilities.

Building Complex Objects:

Similarly, software objects often need multiple capabilities:

A WebApplication HAS-A Router, Database, Cache, Logger, AuthService, etc.
A Game HAS-A Renderer, PhysicsEngine, AudioSystem, InputHandler, etc.
A TradingBot HAS-A MarketDataFeed, OrderExecutor, RiskManager, Logger, etc.

multiple-has-a.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
// A complex object built from multiple components
public class SmartHome {
    // Multiple HAS-A relationships
    private final SecuritySystem security;
    private final ClimateControl climate;
    private final LightingSystem lighting;
    private final EntertainmentSystem entertainment;
    private final EnergyMonitor energy;
    private final List<Sensor> sensors;
    private final NotificationService notifications;
    
    // Constructor injection of all components
    public SmartHome(
            SecuritySystem security,
            ClimateControl climate,
            LightingSystem lighting,
            EntertainmentSystem entertainment,
            EnergyMonitor energy,
            List<Sensor> sensors,
            NotificationService notifications) {
        this.security = security;
        this.climate = climate;
        this.lighting = lighting;
        this.entertainment = entertainment;
        this.energy = energy;
        this.sensors = sensors;
        this.notifications = notifications;
    }
    
    // Coordinate multiple components for complex behaviors
    public void setAwayMode() {
        security.arm();
        climate.setEcoMode();
        lighting.turnOffAll();
        entertainment.turnOff();
        notifications.send("Home set to away mode");
    }
    
    public void setHomeMode() {
        security.disarm();
        climate.setComfortMode();
        lighting.setWelcomeScene();
    }
    
    public void handleMotionDetected(Sensor sensor) {
        if (security.isArmed()) {
            security.alertMotion(sensor.getLocation());
            notifications.sendUrgent("Motion detected: " + sensor.getLocation());
            lighting.turnOnAt(sensor.getLocation());  // Illuminate the area
        }
    }
    
    public EnergyReport getDailyEnergyReport() {
        return new EnergyReport(
            energy.getTodayUsage(),
            climate.getEnergyUsage(),
            lighting.getEnergyUsage(),
            entertainment.getEnergyUsage()
        );
    }
    
    // Each component can be accessed individually if needed
    public SecuritySystem getSecurity() { return security; }
    public ClimateControl getClimate() { return climate; }
    // ... etc
}
 
// This would be IMPOSSIBLE with inheritance
// You can't write: class SmartHome extends SecuritySystem, ClimateControl, ...

The Coordinator Role:

When an object has many components, it often plays a coordinator role—orchestrating the components to achieve higher-level behaviors. The coordinator:

Knows about all components and how they interact
Implements workflows that span multiple components
Maintains overall consistency and invariants
Exposes a unified interface to clients

This is the natural pattern for complex systems: decompose into specialized components, then compose them with a coordinator that manages their interactions.

Composition vs Interface Implementation

When HAS-A Is The Right Choice

Now that we understand HAS-A, when should we prefer it over IS-A (inheritance)? Here are the key indicators:

Choose HAS-A When:

HAS-A Is Appropriate When...

•The relationship is containment, not identity — "Car contains Engine" not "Car is a kind of Engine"
•You need runtime flexibility — Components can be swapped or configured differently for different instances
•Multiple capabilities are needed — You need behavior from several sources (interfaces alone won't provide the implementation)
•The component is reusable across contexts — The same Logger can be used by many different classes
•You want encapsulation — Internal components are hidden; clients interact only with the containing class
•You need to test in isolation — Mock components can be injected for testing
•The relationship might change — Today's component might be replaced with a better one tomorrow
•You're integrating third-party code — You can't inherit from sealed/final classes, but you can contain them

The Litmus Test:

Ask yourself: "Would it make sense to substitute the whole for the part?"

If yes (a Dog can be used where Animal is expected) → IS-A might apply
If no (a Car cannot be used where Engine is expected) → HAS-A applies

Also ask: "Does the whole need to be a specialized version of the part?"

If yes → IS-A relationship
If no, just needs the part's functionality → HAS-A relationship

Good HAS-A Examples

•Car HAS-A Engine
•Department HAS-A List<Employee>
•Order HAS-A List<OrderLine>
•Game HAS-A Renderer
•Controller HAS-A Service
•EmailSender HAS-A SMTPClient

Bad HAS-A (Should Be IS-A)

•Dog HAS-A Animal traits ❌
•PdfDocument HAS-A Document ❌
•SavingsAccount HAS-A BankAccount ❌
•Manager HAS-A Employee ❌
•Square HAS-A Rectangle ❌
•HttpException HAS-A Exception ❌

Summary: The HAS-A Relationship

We've developed a thorough understanding of HAS-A—the composition relationship that models containment and assembly. Let's consolidate the key insights:

Key Takeaways

•HAS-A means containment — One object contains another as a component, not as a type classification
•Composition vs Aggregation — Composition implies lifecycle ownership; aggregation implies shared references
•Delegation is the mechanism — The container forwards calls to components to expose their behavior
•Runtime flexibility — Components can be swapped, configured, or changed at runtime
•Multiple components are natural — Unlike single inheritance, you can compose any number of components
•Encapsulation preserved — Components can be hidden, with only selected behavior exposed
•Use when relationship is containment, not identity — "Contains" not "is a kind of"

What's Next:

Page Complete

2 / 4