System Design (LLD)Relationships Between Objects

Relationships Between Objects

LevelBeginner

Duration60 mins

TopicRelationships Between Objects

2 / 4

Dependency — Objects That Use Each Other

The Lightest Touch

Not all object relationships are created equal. While association represents an ongoing structural bond, dependency represents the lightest, most transient form of relationship—one object uses another temporarily, without maintaining any lasting reference.

Think of it this way: if association is a marriage (a committed, ongoing relationship), dependency is asking a stranger for directions (a brief interaction that ends immediately afterward). The stranger helped you, but you don't exchange numbers. You don't maintain a relationship. You simply used their knowledge in that moment.

Dependency is the relationship of minimal coupling. Understanding it—and knowing when to use it instead of association—is crucial for building systems that are flexible, testable, and maintainable.

What You Will Learn

By the end of this page, you will understand: (1) The precise definition of dependency and how it differs from association, (2) How to identify dependencies vs associations from design decisions, (3) Types of dependencies: parameter, local, static, and return type, (4) How dependencies appear in code and diagrams, (5) The relationship between dependency and coupling, and (6) Techniques for managing and reducing dependencies.

What Is Dependency?

Dependency is a semantic relationship where a change in one element (the supplier) may affect the semantics of another element (the client), but not necessarily vice versa.

In simpler terms: Class A depends on Class B if A uses B in some way without maintaining an ongoing reference to B. The "usage" is transient—it happens during a method call and then ends.

Formal Definition (UML)

In UML, a dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. The dependent element (client) is incomplete without the element(s) it depends on (supplier).

Key Characteristics of Dependency:

Transient Usage: The client uses the supplier temporarily—typically within a single method call. No reference is stored as an instance variable.
No Navigation Path: Unlike association, there's no permanent path from client to supplier. The client finds the supplier through parameters, local instantiation, or static access.
Minimal Coupling: Dependency is the weakest form of coupling. Changing the supplier might break the client, but the connection is localized to specific methods.
One-Directional Awareness: The client knows about and uses the supplier. The supplier typically has no knowledge of the client.

Dependency vs Association: Key Distinctions
Aspect	Dependency	Association
Duration	Transient (during method execution)	Persistent (stored in instance variable)
Reference Storage	None—used and discarded	Maintained as a field
UML Notation	Dashed arrow (------→)	Solid line (——————)
Coupling Strength	Weak—changes affect specific methods	Stronger—affects class structure
Example	Method receives Logger as parameter	Order holds reference to Customer
Typical Lifespan	Method call duration	Object lifetime

Types of Dependencies

Dependencies manifest in several distinct forms, each with different implications for coupling and design flexibility. Understanding these types helps you make conscious choices about how your classes interact.

Dependency Categories

•Parameter Dependency: The supplier is passed as a method/constructor parameter. This is the most visible and explicit form of dependency.
•Local Variable Dependency: The supplier is instantiated as a local variable within a method. This is harder to see from the class interface.
•Static/Global Dependency: The client calls static methods or accesses global state on the supplier. Often hidden and difficult to test.
•Return Type Dependency: The client depends on the supplier because a method returns an instance of the supplier type.
•Instantiation Dependency: The client creates (instantiates) the supplier using new. The client depends on the concrete class.

DependencyTypes.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
public class PaymentProcessor {
    
    // 1. PARAMETER DEPENDENCY
    // Logger is passed in—explicit, visible, testable
    public void processPayment(Payment payment, Logger logger) {
        logger.info("Processing payment: " + payment.getId());
        // Process payment...
    }
    
    // 2. LOCAL VARIABLE DEPENDENCY 
    // Validator is created locally—hidden, harder to test
    public boolean validateCard(CreditCard card) {
        CardValidator validator = new CardValidator();  // Hidden dependency!
        return validator.isValid(card);
    }
    
    // 3. STATIC/GLOBAL DEPENDENCY
    // Depends on static method—hidden, hard to replace
    public Money convertCurrency(Money amount, Currency targetCurrency) {
        double rate = ExchangeRateService.getRate(  // Static dependency!
            amount.getCurrency(), 
            targetCurrency
        );
        return amount.multiply(rate);
    }
    
    // 4. RETURN TYPE DEPENDENCY
    // PaymentResult must be known to callers of this method
    public PaymentResult executeTransaction(Transaction tx) {
        // Process transaction...
        return new PaymentResult(status, message);  // Return type dependency
    }
    
    // 5. INSTANTIATION DEPENDENCY
    // Directly instantiates concrete class—tight coupling
    public Receipt generateReceipt(Payment payment) {
        PdfGenerator generator = new PdfGenerator();  // Concrete class!
        return generator.create(payment);
    }
}

Hidden Dependencies Are Dangerous

Local variable, static, and instantiation dependencies are concerning because they're hidden from the class's public interface. A class that appears to have no dependencies might actually be tightly coupled to half a dozen concrete implementations internally. This makes testing and refactoring extremely difficult.

Representing Dependency in UML

In UML class diagrams, dependency is represented by a dashed arrow pointing from the client (dependent) to the supplier (dependency). The arrow indicates direction: "Client depends on Supplier."

┌──────────────┐          ┌──────────────┐
│    Client    │ -------> │   Supplier   │
└──────────────┘          └──────────────┘
       │                         │
       │                         │
    Depends on             Required by

UML Dependency Stereotypes:

UML allows optional stereotypes to specify the nature of the dependency:

Stereotype	Meaning	Example
«use»	Client uses features of supplier	Method calls another class
«create»	Client instantiates supplier	Factory creates objects
«instantiate»	Client creates instances of supplier class	new Supplier()
«derive»	Client's value is derived from supplier	Calculated property based on other class
«call»	Client invokes operations on supplier	Method invocation during execution
«permit»	Client has special access to supplier	Friend class or internal access

Reading Dependency Diagrams:

When you see a dashed arrow from A to B, read it as:

"A depends on B"
"A uses B"
"If B changes, A might be affected"
"A cannot be compiled/understood without B"
"A does not store a reference to B"

Dependency vs Association in Diagrams

When deciding whether to draw a solid line (association) or dashed line (dependency), ask: "Does the source class store a reference to the target as a field?" If yes, use association (solid). If the class only uses the target temporarily in methods, use dependency (dashed).

Dependency and Coupling

Coupling refers to how tightly two modules or classes are connected. High coupling means changes in one class ripple to others; low coupling means classes can change independently.

Dependency is inherently about coupling—every dependency is a coupling point. The goal is not to eliminate all coupling (impossible—software must connect somewhere) but to:

Minimize the number of dependencies
Depend on abstractions rather than concretions
Make dependencies explicit and visible
Reduce the scope of change propagation

Coupling Spectrum by Relationship Type
Relationship	Coupling Level	Change Impact	Testability
Dependency on Interface	Very Low	Minimal—interface changes are rare	Excellent—easily mocked
Dependency on Abstract Class	Low	Low—implementation changes don't affect client	Good—substitutable
Association	Medium	Moderate—structural changes propagate	Moderate—requires setup
Dependency on Concrete Class	Medium-High	High—any change might break client	Difficult—hard to isolate
Composition	High	High—lifecycle is tied	Challenging—complex setup
Inheritance	Very High	Very High—base class changes break all subclasses	Fragile—hard to test in isolation

The Dependency Inversion Principle

High-level modules should not depend on low-level modules. Both should depend on abstractions. This means your business logic (PaymentProcessor) shouldn't directly depend on infrastructure (MySQLDatabase). Both should depend on an abstraction (PaymentRepository interface). This inverts the typical dependency direction and dramatically reduces coupling.

DependencyInversion.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
// ❌ HIGH COUPLING: Direct dependency on concrete class
public class OrderService {
    public void placeOrder(Order order) {
        // Direct dependency on concrete database implementation
        MySQLDatabase db = new MySQLDatabase();
        db.save(order);
        
        // Direct dependency on concrete email sender
        SmtpEmailSender emailer = new SmtpEmailSender();
        emailer.send("Order placed: " + order.getId());
    }
}
 
// ✅ LOW COUPLING: Dependency on abstractions
public class OrderService {
    private final OrderRepository repository;  // Depends on interface!
    private final NotificationService notifier;  // Depends on interface!
    
    // Dependencies are injected, not created
    public OrderService(OrderRepository repository, NotificationService notifier) {
        this.repository = repository;
        this.notifier = notifier;
    }
    
    public void placeOrder(Order order) {
        repository.save(order);  // Works with any implementation
        notifier.notify("Order placed: " + order.getId());  // Flexible!
    }
}
 
// Now we can substitute implementations:
// - Use InMemoryRepository for testing
// - Use MySQLRepository for production
// - Use PushNotificationService for mobile
// - Use EmailNotificationService for web

When to Use Dependency vs Association

One of the most common design decisions is choosing between dependency and association. The choice has significant implications for coupling, testability, and design flexibility.

The fundamental question: Does the client need to remember the supplier, or just use it momentarily?

Use Dependency When...

•The supplier is used in only one or two methods
•The relationship is conceptually about service usage, not ownership
•You want maximum flexibility to substitute different implementations
•The supplier is stateless or is shared across many clients
•Testing in isolation is important
•Example: PaymentProcessor uses Logger

Use Association When...

•The client needs ongoing access to the supplier
•The relationship is central to the client's identity or purpose
•The supplier is needed across many methods in the client
•The domain model naturally describes an ongoing relationship
•Performance matters—avoiding repeated lookups
•Example: Order has a Customer

Case Study: Report Generation

Consider a ReportGenerator that produces PDF reports. Should it have a dependency or association with a PDFWriter?

DependencyVsAssociation.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
// Option A: Association (if PDFWriter is used throughout the class)
public class ReportGenerator {
    private final PDFWriter pdfWriter;  // Stored reference
    
    public ReportGenerator(PDFWriter pdfWriter) {
        this.pdfWriter = pdfWriter;
    }
    
    public Report generate(ReportData data) {
        pdfWriter.startDocument();
        pdfWriter.addHeader(data.getTitle());
        pdfWriter.addBody(data.getContent());
        pdfWriter.addFooter(data.getFooter());
        return pdfWriter.finishDocument();
    }
}
 
// Option B: Dependency (if PDFWriter is just a method parameter)
public class ReportGenerator {
    // No stored reference to PDFWriter
    
    public Report generate(ReportData data, PDFWriter pdfWriter) {
        pdfWriter.startDocument();
        pdfWriter.addHeader(data.getTitle());
        pdfWriter.addBody(data.getContent());
        pdfWriter.addFooter(data.getFooter());
        return pdfWriter.finishDocument();
    }
}
 
// Which is better? It depends:
// - If ReportGenerator always uses the same PDFWriter → Association
// - If different callers need different writers → Dependency
// - If PDFWriter needs configuration that varies → Dependency
// - If testing requires substituting PDFWriter → Either works with DI

When in Doubt, Choose Dependency

If you're unsure whether to use dependency or association, lean toward dependency. It's easier to upgrade a dependency to an association later than to downgrade an association to a dependency. Start with the weakest coupling that works.

Techniques for Managing Dependencies

Unmanaged dependencies lead to systems that are difficult to test, modify, and understand. Here are established techniques for managing dependencies effectively:

Dependency Management Strategies

•
Dependency Injection (DI): Instead of a class creating its dependencies, they're provided (injected) from outside. This makes dependencies explicit and substitutable.
- Constructor Injection: Dependencies provided in constructor (recommended)
- Setter Injection: Dependencies set via setter methods
- Interface Injection: Dependencies provided via interface method
•Depend on Interfaces: Instead of depending on concrete classes, depend on interfaces or abstract classes. This follows the Dependency Inversion Principle.
•Service Locator Pattern: Use a central registry to look up dependencies. Less explicit than DI but sometimes useful for legacy code.
•Factory Pattern: Use factories to create dependencies. The client depends on the factory interface, not the concrete classes.
•Composition Root: Centralize all object creation and wiring in one place at the application entry point. This keeps construction logic out of business classes.

DependencyManagement.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
77
// CONSTRUCTOR INJECTION (Recommended)
public class OrderProcessor {
    private final PaymentGateway paymentGateway;
    private final InventoryService inventory;
    private final EmailService emailService;
    
    // All dependencies injected through constructor
    public OrderProcessor(
        PaymentGateway paymentGateway,
        InventoryService inventory,
        EmailService emailService
    ) {
        this.paymentGateway = paymentGateway;
        this.inventory = inventory;
        this.emailService = emailService;
    }
    
    public OrderResult process(Order order) {
        // Use injected dependencies—easily testable!
        if (!inventory.isAvailable(order.getItems())) {
            return OrderResult.outOfStock();
        }
        
        PaymentResult payment = paymentGateway.charge(order.getTotal());
        if (!payment.isSuccess()) {
            return OrderResult.paymentFailed();
        }
        
        inventory.reserve(order.getItems());
        emailService.sendConfirmation(order);
        
        return OrderResult.success();
    }
}
 
// COMPOSITION ROOT: Wire everything at startup
public class Application {
    public static void main(String[] args) {
        // Create concrete implementations
        PaymentGateway paymentGateway = new StripePaymentGateway();
        InventoryService inventory = new DatabaseInventoryService();
        EmailService emailService = new SmtpEmailService();
        
        // Inject dependencies
        OrderProcessor processor = new OrderProcessor(
            paymentGateway,
            inventory,
            emailService
        );
        
        // Use the fully-wired processor
        processor.process(order);
    }
}
 
// For testing, inject mocks:
public class OrderProcessorTest {
    @Test
    void successfulOrder() {
        // Arrange
        PaymentGateway mockPayment = mock(PaymentGateway.class);
        when(mockPayment.charge(any())).thenReturn(success());
        
        InventoryService mockInventory = mock(InventoryService.class);
        when(mockInventory.isAvailable(any())).thenReturn(true);
        
        EmailService mockEmail = mock(EmailService.class);
        
        OrderProcessor processor = new OrderProcessor(
            mockPayment, mockInventory, mockEmail
        );
        
        // Act & Assert
        OrderResult result = processor.process(testOrder);
        assertEquals(OrderResult.success(), result);
    }
}

Common Dependency Pitfalls

Dependency Anti-Patterns

•Hidden Dependencies (new Keyword Abuse): Creating dependencies inside methods using new hides them from the class's interface. Prefer injection for anything that might need substitution.
•Static Method Dependencies: Calling static methods creates invisible, hard-to-test dependencies. Wrap static utilities behind interfaces when possible.
•Circular Dependencies: When A depends on B and B depends on A. This often signals a design flaw—classes are doing too much or responsibilities are misallocated.
•Dependency Sprawl: When a class has too many dependencies (more than 4-5 constructor parameters is a smell). Consider if the class has too many responsibilities.
•Transitive Dependency Leakage: When A→B→C causes A to effectively depend on C. Changes in C break A even though they're not directly related.
•Ignoring the Dependency Inversion Principle: High-level business logic depending directly on low-level infrastructure (databases, HTTP clients, file systems).

The Service Locator Trap

While Service Locator can manage dependencies, it often becomes a "God object" that everything depends on. It hides dependencies (you can't tell what a class needs from its constructor) and makes testing harder (every test needs to configure the locator). Prefer constructor injection in new code.

Summary: The Art of Light Coupling

Dependency represents the minimal form of relationship between objects. Mastering dependencies is essential for building flexible, testable systems.

Key Takeaways

•Dependency is transient: Unlike association, dependencies don't persist as stored references. They exist during method execution only.
•Five types exist: Parameter, local variable, static, return type, and instantiation dependencies each have different implications.
•UML uses dashed arrows: The dashed line distinguishes dependency from association's solid line.
•Dependencies create coupling: Every dependency is a potential break point. Minimize, abstract, and make dependencies explicit.
•Dependency Injection is key: Inject dependencies rather than creating them internally. This makes classes testable and flexible.
•Prefer interfaces: Depend on abstractions, not concrete implementations. This follows the Dependency Inversion Principle.
•Watch for hidden dependencies: Static calls and new inside methods hide dependencies from the class interface.

Coming Up Next:

We've covered association (ongoing relationship) and dependency (transient usage). Next, we dive into Aggregation—a special form of association that models whole-part relationships where the parts can exist independently of the whole. Think of a Department with Employees—if the Department closes, the Employees don't cease to exist.

Page Complete

You now understand dependency—the lightest form of object relationship. You can identify dependency types, represent them in UML, and apply techniques like Dependency Injection to manage coupling effectively.

2 / 4

Loading learning content...

System Design (LLD)Relationships Between Objects

Relationships Between Objects

LevelBeginner

Duration60 mins

TopicRelationships Between Objects

2 / 4

Dependency — Objects That Use Each Other

The Lightest Touch

What You Will Learn

What Is Dependency?

Dependency is a semantic relationship where a change in one element (the supplier) may affect the semantics of another element (the client), but not necessarily vice versa.

In simpler terms: Class A depends on Class B if A uses B in some way without maintaining an ongoing reference to B. The "usage" is transient—it happens during a method call and then ends.

Formal Definition (UML)

Key Characteristics of Dependency:

Transient Usage: The client uses the supplier temporarily—typically within a single method call. No reference is stored as an instance variable.
No Navigation Path: Unlike association, there's no permanent path from client to supplier. The client finds the supplier through parameters, local instantiation, or static access.
Minimal Coupling: Dependency is the weakest form of coupling. Changing the supplier might break the client, but the connection is localized to specific methods.
One-Directional Awareness: The client knows about and uses the supplier. The supplier typically has no knowledge of the client.

Dependency vs Association: Key Distinctions
Aspect	Dependency	Association
Duration	Transient (during method execution)	Persistent (stored in instance variable)
Reference Storage	None—used and discarded	Maintained as a field
UML Notation	Dashed arrow (------→)	Solid line (——————)
Coupling Strength	Weak—changes affect specific methods	Stronger—affects class structure
Example	Method receives Logger as parameter	Order holds reference to Customer
Typical Lifespan	Method call duration	Object lifetime

Types of Dependencies

Dependency Categories

•Parameter Dependency: The supplier is passed as a method/constructor parameter. This is the most visible and explicit form of dependency.
•Local Variable Dependency: The supplier is instantiated as a local variable within a method. This is harder to see from the class interface.
•Static/Global Dependency: The client calls static methods or accesses global state on the supplier. Often hidden and difficult to test.
•Return Type Dependency: The client depends on the supplier because a method returns an instance of the supplier type.
•Instantiation Dependency: The client creates (instantiates) the supplier using new. The client depends on the concrete class.

DependencyTypes.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
public class PaymentProcessor {
    
    // 1. PARAMETER DEPENDENCY
    // Logger is passed in—explicit, visible, testable
    public void processPayment(Payment payment, Logger logger) {
        logger.info("Processing payment: " + payment.getId());
        // Process payment...
    }
    
    // 2. LOCAL VARIABLE DEPENDENCY 
    // Validator is created locally—hidden, harder to test
    public boolean validateCard(CreditCard card) {
        CardValidator validator = new CardValidator();  // Hidden dependency!
        return validator.isValid(card);
    }
    
    // 3. STATIC/GLOBAL DEPENDENCY
    // Depends on static method—hidden, hard to replace
    public Money convertCurrency(Money amount, Currency targetCurrency) {
        double rate = ExchangeRateService.getRate(  // Static dependency!
            amount.getCurrency(), 
            targetCurrency
        );
        return amount.multiply(rate);
    }
    
    // 4. RETURN TYPE DEPENDENCY
    // PaymentResult must be known to callers of this method
    public PaymentResult executeTransaction(Transaction tx) {
        // Process transaction...
        return new PaymentResult(status, message);  // Return type dependency
    }
    
    // 5. INSTANTIATION DEPENDENCY
    // Directly instantiates concrete class—tight coupling
    public Receipt generateReceipt(Payment payment) {
        PdfGenerator generator = new PdfGenerator();  // Concrete class!
        return generator.create(payment);
    }
}

Hidden Dependencies Are Dangerous

Representing Dependency in UML

In UML class diagrams, dependency is represented by a dashed arrow pointing from the client (dependent) to the supplier (dependency). The arrow indicates direction: "Client depends on Supplier."

┌──────────────┐          ┌──────────────┐
│    Client    │ -------> │   Supplier   │
└──────────────┘          └──────────────┘
       │                         │
       │                         │
    Depends on             Required by

UML Dependency Stereotypes:

UML allows optional stereotypes to specify the nature of the dependency:

Stereotype	Meaning	Example
«use»	Client uses features of supplier	Method calls another class
«create»	Client instantiates supplier	Factory creates objects
«instantiate»	Client creates instances of supplier class	new Supplier()
«derive»	Client's value is derived from supplier	Calculated property based on other class
«call»	Client invokes operations on supplier	Method invocation during execution
«permit»	Client has special access to supplier	Friend class or internal access

Reading Dependency Diagrams:

When you see a dashed arrow from A to B, read it as:

"A depends on B"
"A uses B"
"If B changes, A might be affected"
"A cannot be compiled/understood without B"
"A does not store a reference to B"

Dependency vs Association in Diagrams

Dependency and Coupling

Coupling refers to how tightly two modules or classes are connected. High coupling means changes in one class ripple to others; low coupling means classes can change independently.

Dependency is inherently about coupling—every dependency is a coupling point. The goal is not to eliminate all coupling (impossible—software must connect somewhere) but to:

Minimize the number of dependencies
Depend on abstractions rather than concretions
Make dependencies explicit and visible
Reduce the scope of change propagation

Coupling Spectrum by Relationship Type
Relationship	Coupling Level	Change Impact	Testability
Dependency on Interface	Very Low	Minimal—interface changes are rare	Excellent—easily mocked
Dependency on Abstract Class	Low	Low—implementation changes don't affect client	Good—substitutable
Association	Medium	Moderate—structural changes propagate	Moderate—requires setup
Dependency on Concrete Class	Medium-High	High—any change might break client	Difficult—hard to isolate
Composition	High	High—lifecycle is tied	Challenging—complex setup
Inheritance	Very High	Very High—base class changes break all subclasses	Fragile—hard to test in isolation

The Dependency Inversion Principle

DependencyInversion.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
// ❌ HIGH COUPLING: Direct dependency on concrete class
public class OrderService {
    public void placeOrder(Order order) {
        // Direct dependency on concrete database implementation
        MySQLDatabase db = new MySQLDatabase();
        db.save(order);
        
        // Direct dependency on concrete email sender
        SmtpEmailSender emailer = new SmtpEmailSender();
        emailer.send("Order placed: " + order.getId());
    }
}
 
// ✅ LOW COUPLING: Dependency on abstractions
public class OrderService {
    private final OrderRepository repository;  // Depends on interface!
    private final NotificationService notifier;  // Depends on interface!
    
    // Dependencies are injected, not created
    public OrderService(OrderRepository repository, NotificationService notifier) {
        this.repository = repository;
        this.notifier = notifier;
    }
    
    public void placeOrder(Order order) {
        repository.save(order);  // Works with any implementation
        notifier.notify("Order placed: " + order.getId());  // Flexible!
    }
}
 
// Now we can substitute implementations:
// - Use InMemoryRepository for testing
// - Use MySQLRepository for production
// - Use PushNotificationService for mobile
// - Use EmailNotificationService for web

When to Use Dependency vs Association

One of the most common design decisions is choosing between dependency and association. The choice has significant implications for coupling, testability, and design flexibility.

The fundamental question: Does the client need to remember the supplier, or just use it momentarily?

Use Dependency When...

•The supplier is used in only one or two methods
•The relationship is conceptually about service usage, not ownership
•You want maximum flexibility to substitute different implementations
•The supplier is stateless or is shared across many clients
•Testing in isolation is important
•Example: PaymentProcessor uses Logger

Use Association When...

•The client needs ongoing access to the supplier
•The relationship is central to the client's identity or purpose
•The supplier is needed across many methods in the client
•The domain model naturally describes an ongoing relationship
•Performance matters—avoiding repeated lookups
•Example: Order has a Customer

Case Study: Report Generation

Consider a ReportGenerator that produces PDF reports. Should it have a dependency or association with a PDFWriter?

DependencyVsAssociation.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
// Option A: Association (if PDFWriter is used throughout the class)
public class ReportGenerator {
    private final PDFWriter pdfWriter;  // Stored reference
    
    public ReportGenerator(PDFWriter pdfWriter) {
        this.pdfWriter = pdfWriter;
    }
    
    public Report generate(ReportData data) {
        pdfWriter.startDocument();
        pdfWriter.addHeader(data.getTitle());
        pdfWriter.addBody(data.getContent());
        pdfWriter.addFooter(data.getFooter());
        return pdfWriter.finishDocument();
    }
}
 
// Option B: Dependency (if PDFWriter is just a method parameter)
public class ReportGenerator {
    // No stored reference to PDFWriter
    
    public Report generate(ReportData data, PDFWriter pdfWriter) {
        pdfWriter.startDocument();
        pdfWriter.addHeader(data.getTitle());
        pdfWriter.addBody(data.getContent());
        pdfWriter.addFooter(data.getFooter());
        return pdfWriter.finishDocument();
    }
}
 
// Which is better? It depends:
// - If ReportGenerator always uses the same PDFWriter → Association
// - If different callers need different writers → Dependency
// - If PDFWriter needs configuration that varies → Dependency
// - If testing requires substituting PDFWriter → Either works with DI

When in Doubt, Choose Dependency

Techniques for Managing Dependencies

Unmanaged dependencies lead to systems that are difficult to test, modify, and understand. Here are established techniques for managing dependencies effectively:

Dependency Management Strategies

•
Dependency Injection (DI): Instead of a class creating its dependencies, they're provided (injected) from outside. This makes dependencies explicit and substitutable.
- Constructor Injection: Dependencies provided in constructor (recommended)
- Setter Injection: Dependencies set via setter methods
- Interface Injection: Dependencies provided via interface method
•Depend on Interfaces: Instead of depending on concrete classes, depend on interfaces or abstract classes. This follows the Dependency Inversion Principle.
•Service Locator Pattern: Use a central registry to look up dependencies. Less explicit than DI but sometimes useful for legacy code.
•Factory Pattern: Use factories to create dependencies. The client depends on the factory interface, not the concrete classes.
•Composition Root: Centralize all object creation and wiring in one place at the application entry point. This keeps construction logic out of business classes.

DependencyManagement.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
77
// CONSTRUCTOR INJECTION (Recommended)
public class OrderProcessor {
    private final PaymentGateway paymentGateway;
    private final InventoryService inventory;
    private final EmailService emailService;
    
    // All dependencies injected through constructor
    public OrderProcessor(
        PaymentGateway paymentGateway,
        InventoryService inventory,
        EmailService emailService
    ) {
        this.paymentGateway = paymentGateway;
        this.inventory = inventory;
        this.emailService = emailService;
    }
    
    public OrderResult process(Order order) {
        // Use injected dependencies—easily testable!
        if (!inventory.isAvailable(order.getItems())) {
            return OrderResult.outOfStock();
        }
        
        PaymentResult payment = paymentGateway.charge(order.getTotal());
        if (!payment.isSuccess()) {
            return OrderResult.paymentFailed();
        }
        
        inventory.reserve(order.getItems());
        emailService.sendConfirmation(order);
        
        return OrderResult.success();
    }
}
 
// COMPOSITION ROOT: Wire everything at startup
public class Application {
    public static void main(String[] args) {
        // Create concrete implementations
        PaymentGateway paymentGateway = new StripePaymentGateway();
        InventoryService inventory = new DatabaseInventoryService();
        EmailService emailService = new SmtpEmailService();
        
        // Inject dependencies
        OrderProcessor processor = new OrderProcessor(
            paymentGateway,
            inventory,
            emailService
        );
        
        // Use the fully-wired processor
        processor.process(order);
    }
}
 
// For testing, inject mocks:
public class OrderProcessorTest {
    @Test
    void successfulOrder() {
        // Arrange
        PaymentGateway mockPayment = mock(PaymentGateway.class);
        when(mockPayment.charge(any())).thenReturn(success());
        
        InventoryService mockInventory = mock(InventoryService.class);
        when(mockInventory.isAvailable(any())).thenReturn(true);
        
        EmailService mockEmail = mock(EmailService.class);
        
        OrderProcessor processor = new OrderProcessor(
            mockPayment, mockInventory, mockEmail
        );
        
        // Act & Assert
        OrderResult result = processor.process(testOrder);
        assertEquals(OrderResult.success(), result);
    }
}

Common Dependency Pitfalls

Dependency Anti-Patterns

•Hidden Dependencies (new Keyword Abuse): Creating dependencies inside methods using new hides them from the class's interface. Prefer injection for anything that might need substitution.
•Static Method Dependencies: Calling static methods creates invisible, hard-to-test dependencies. Wrap static utilities behind interfaces when possible.
•Circular Dependencies: When A depends on B and B depends on A. This often signals a design flaw—classes are doing too much or responsibilities are misallocated.
•Dependency Sprawl: When a class has too many dependencies (more than 4-5 constructor parameters is a smell). Consider if the class has too many responsibilities.
•Transitive Dependency Leakage: When A→B→C causes A to effectively depend on C. Changes in C break A even though they're not directly related.
•Ignoring the Dependency Inversion Principle: High-level business logic depending directly on low-level infrastructure (databases, HTTP clients, file systems).

The Service Locator Trap

Summary: The Art of Light Coupling

Dependency represents the minimal form of relationship between objects. Mastering dependencies is essential for building flexible, testable systems.

Key Takeaways

•Dependency is transient: Unlike association, dependencies don't persist as stored references. They exist during method execution only.
•Five types exist: Parameter, local variable, static, return type, and instantiation dependencies each have different implications.
•UML uses dashed arrows: The dashed line distinguishes dependency from association's solid line.
•Dependencies create coupling: Every dependency is a potential break point. Minimize, abstract, and make dependencies explicit.
•Dependency Injection is key: Inject dependencies rather than creating them internally. This makes classes testable and flexible.
•Prefer interfaces: Depend on abstractions, not concrete implementations. This follows the Dependency Inversion Principle.
•Watch for hidden dependencies: Static calls and new inside methods hide dependencies from the class interface.

Coming Up Next:

Page Complete

2 / 4