Dependency

Dependency is the most flexible and weakest structural relationship between classes in Object-Oriented Design. It represents a transient, short-term connection where one class utilizes another class (frequently as a method parameter, local variable, or return type) to perform a specific task, without holding any persistent reference to it.

1. Learning Objectives

• Define Dependency and identify its UML dashed arrow representation.
• Distinguish Dependency from Association, Aggregation, and Composition based on field retention and lifetime.
• Implement transient parameters in Java, Python, and C++ class methods.
• Trace stack allocations and method frame registers to understand where dependencies reside in memory.
• Apply the Dependency Inversion Principle (DIP) to decouple service dependency paths.

2. Problem Statement

In a complex software application, classes must interact to execute tasks. However, if a class holds persistent instance fields (Association) for every auxiliary tool, calculator, database driver, or data transfer object it uses, we run into major design issues:

• High Memory Consumption: Storing references as fields keeps them allocated on the heap long after the operation is complete.
• Thread-Safety Violations: Sharing stateful objects like Order or PaymentTransaction as instance variables across multi-threaded services causes race conditions.
• Rigid Architecture: Hardcoding dependencies limits our ability to swap implementations or test classes in isolation.

We need a way to design classes so they use other objects temporarily during a specific method execution, rather than maintaining permanent links.

3. Real-world Analogy

4. Theory

Dependency represents a "uses-a" relationship. It is the weakest form of class relationship, indicating that a change in the definition of one class (e.g., class B) may affect another class (e.g., class A) because class A uses class B, even if it doesn't store a reference to it.

Key Characteristics:

• Transient Context: The connection is established only for the duration of a method call or execution block.
• No Field Storage: The dependent class does not define instance variables pointing to the target class.
• UML Representation: Indicated by a dashed arrow line pointing from the dependent class to the class being used.

Common Manifestations of Dependency:

1. Method Parameter: The target object is passed as a method argument: process(Order order).
2. Local Variable: The target object is instantiated inside the method: Calculator calc = new Calculator().
3. Method Return Type: The target object is returned by a method: public Order getOrder().

5. Visual Diagrams (UML & Memory structures)

Class Diagram

Dashed arrows point to classes that are used temporarily. PaymentService depends on Order and PaymentGateway.

Memory Diagram (Transient Stack Frame)

When processPayment is invoked, references to order and gateway are pushed onto the method's stack frame. When the method finishes execution, the stack frame is popped, and these temporary pointers are discarded.

Object Lifecycle

6. Syntax Explanation

Dependency is declared by referencing another type inside method signatures, local blocks, or return signatures, rather than declaring instance fields:

• Java: Methods accept references, e.g., public boolean process(Order order, PaymentGateway gateway). Interfaces are preferred for parameters to keep dependencies decoupled (Dependency Inversion).
• Python: Uses method parameters. Type hints, e.g. def process(self, order: 'Order', gateway: 'PaymentGateway') -> bool:, help document the dependency.
• C++: Parameters are passed as references or pointers to prevent unnecessary object slicing or copying: bool process(const Order& order, PaymentGateway* gateway).

7. Step-by-Step Implementation

• Step 1: Create the Order entity representing the data package.
• Step 2: Create the PaymentGateway interface (representing the abstraction) and a concrete implementation class StripeGateway.
• Step 3: Create the PaymentService class. Do not define any fields. Declare a method processOrderPayment that takes Order and PaymentGateway as arguments.
• Step 4: Write a verification script: instantiate the objects, call the process method, and verify that PaymentService retains no references to the order or gateway after the method completes.

8. Complete Code (Mini Project)

9. Code Walkthrough

The core design feature of the PaymentService class is its complete lack of instance fields:

• The class does not define member variables for Order or PaymentGateway. If it did, it would be an Association instead of a Dependency.
• By declaring parameters in the method signature processOrderPayment(Order order, PaymentGateway gateway), we decouple the lifetime of PaymentService from the database objects and payment adapters it uses.
• In C++, passing arguments as const Order& order and PaymentGateway& gateway avoids copying objects while keeping the runtime dependency light and fast.

10. Execution Flow

1. Construction: PaymentService is instantiated. It has zero fields, taking up minimal heap space.
2. Invocation: The client calls processOrderPayment(order, gateway).
3. Stack Allocation: A new stack frame for the method is created. The memory addresses of the order and gateway are pushed onto this frame.
4. Execution: The service delegates the payment execution to the gateway.
5. Method Pop: The execution returns a boolean. The stack frame is destroyed, and the references are discarded. The service has no remaining connection to either object.

11. Internal Working

During method execution, local references exist only inside the active thread's stack frame.

When paymentService.processOrderPayment(order, gateway) is called, the JVM creates a new stack frame containing slots for local variables (specifically the reference addresses of the arguments).

Once the method returns, its stack frame is popped off. The local reference variables disappear. Since the PaymentService object has no instance fields holding these heap addresses, the garbage collector is free to clean up the order or gateway objects as soon as the client code releases them.

12. Complexity Analysis

• Time Complexity: $O(1)$ to pass references on the stack frame. The execution speed depends entirely on the method's internal logic.
• Space Complexity: $O(1)$ transient stack allocations per call. No heap space is consumed by the calling service.

13. Best Practices

• Depend on abstractions: Always declare method parameters as interface types (e.g., PaymentGateway) rather than concrete classes (e.g., StripeGateway) to keep components decoupled.
• Avoid persistent state inside services: Helper classes, services, and utility classes should remain stateless and accept variables only via method arguments.
• Inject dependencies: When a class needs a service, inject it rather than instantiating the concretion internally.

14. Common Mistakes

• Converting temporary variables into fields: Storing transient variables (like Order data packages) as instance fields in service singletons. This causes memory leaks and severe multi-threading bugs.
• Concrete Instantiation inside methods: Writing PaymentGateway gateway = new StripeGateway() inside a method. This tightly couples the service to a concrete gateway, making it impossible to mock the dependency for unit testing.
• Circular Dependencies: Class A depending on Class B, and Class B depending on Class A. This makes the codebase rigid and difficult to compile. Resolve circular dependencies by introducing interfaces.

15. Interview Questions

16. Practice Exercises

• Easy: Implement a ReportGenerator class that depends on a DateFormatter helper passed to its generate() method.
• Medium: Design a NotificationService class. Implement a sendAlert(User user, MessageTemplate template) method. Ensure the templates are passed transiently.
• Hard: Create a thread-safe FileExporter class. Expose an exportData(Dataset dataset, DataWriter writer) method. Verify that multiple threads can safely execute exports concurrently using different datasets and writer targets.

17. Challenge Problem

Design a custom Dependency Injection (DI) Container from scratch in Java/Python that scans classes, registers dependencies, and injects them dynamically into class methods at runtime.

18. Summary

• Dependency is the weakest relationship, representing temporary "uses-a" behavior.
• Dependencies exist only during execution scope and are not stored in instance fields.
• In UML, Dependency is represented by a dashed arrow pointing to the utilized class.
• Mocking dependencies allows for clean, isolated unit testing.

19. Cheat Sheet

20. Quiz

21. Next Lesson Preview

In the next module, we will explore Design Principles, starting with the DRY (Don't Repeat Yourself) principle to learn how to identify and extract duplicate code layouts!