System Design (LLD)Interface Segregation Principle

The Fat Interfaces Problem

LevelIntermediate

Duration60 mins

TopicInterface Segregation Principle

2 / 4

Unused Method Dependencies

The Dependencies You Never Asked For

Consider a simple analogy: You're renting a car for a weekend trip. The rental company says, "Here's the key to your sedan, but you must also accept responsibility for maintaining the engine, changing the oil, rotating the tires, and keeping the transmission serviced."

"But I just want to drive it for three days," you protest.

"Doesn't matter. The car comes as a complete package. You depend on all of it."

This is precisely what fat interfaces do to your code. When a client depends on a fat interface, it accepts responsibility for dependencies it never asked for and will never use. These unused method dependencies are the hidden tax on every component that touches a bloated interface.

What You Will Learn

By the end of this page, you will understand precisely how unused method dependencies create coupling, why this coupling is particularly insidious, and how to trace the impact of phantom dependencies through your codebase. You will learn to see the invisible threads that tie unrelated components together through fat interfaces.

Understanding Dependency Mechanics

To understand unused method dependencies, we must first understand what it means for code to "depend on" an interface.

What Is a Dependency?

In software, a dependency exists when one code element (the dependent) references another code element (the dependency). This reference can be:

Explicit: Importing a type, calling a method, instantiating a class
Implicit: Relying on behavior, expecting certain invariants

When your class declares a parameter typed as IOrderService, you create a compile-time dependency on that interface. Your code cannot compile unless IOrderService is available and well-defined.

The Transitive Nature of Dependencies:

Dependencies are transitive. If A depends on B, and B depends on C, then A indirectly depends on C. Changes to C can ripple through B to affect A.

DependencyChain.ts
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
// Dependency chain example
 
// C: The leaf dependency
interface PaymentResult {
    transactionId: string;
    status: 'success' | 'failed' | 'pending';
    errorMessage?: string;
}
 
// B: Depends on C (PaymentResult)
interface IOrderService {
    // This method signature creates a dependency on PaymentResult
    processPayment(orderId: string): Promise<PaymentResult>;
    
    // Even if you never call processPayment, if you depend on
    // IOrderService, you transitively depend on PaymentResult
    
    getOrderById(orderId: string): Promise<Order>;
}
 
// A: Depends on B (IOrderService), therefore transitively depends on C
class OrderReporter {
    constructor(private orderService: IOrderService) {}
    
    async generateReport(orderId: string) {
        // Only uses getOrderById
        const order = await this.orderService.getOrderById(orderId);
        return this.formatReport(order);
    }
    
    // OrderReporter never calls processPayment.
    // Yet it depends on PaymentResult because IOrderService references it.
    // If PaymentResult changes, OrderReporter must be recompiled.
}

The Phantom Dependency Problem

OrderReporter has a dependency on PaymentResult—a type it never uses, never references, and whose existence it doesn't even need to know about. This is a phantom dependency: real at compile time, invisible in the code, and a source of unintended coupling.

Categories of Unused Method Dependencies

Unused method dependencies manifest in several distinct forms, each with its own characteristics and impact on system architecture:

Five Categories of Unused Dependencies

•Type Dependencies: The interface references types (as parameters or return values) that the client never touches. Example: IOrderService references ShippingLabel, but the reporting client never deals with shipping.
•Method Signature Dependencies: The client must understand method signatures it never calls. Changes to those signatures require recompilation. Example: processPayment(orderId, amount) changes to processPayment(orderId, amount, currency), affecting all IOrderService consumers.
•Exception Dependencies: The interface declares exceptions that methods might throw. Clients depending on the interface implicitly depend on those exception types. Example: throws PaymentDeclinedException on a payment method creates a dependency even for non-payment clients.
•Documentation Dependencies: In strongly-typed languages, documentation/annotations on unused methods can create tooling dependencies. In some IDEs, documentation generation includes all interface methods.
•Conceptual Dependencies: Developers must understand the unused methods to work with the interface effectively. This cognitive load slows development and increases error risk.

Visualizing the Dependency Web:

Consider a fat IOrderService with 30 methods. Each method may reference 2-3 types (parameters, return types, exceptions). The interface creates a dependency graph:

                          IOrderService
                               │
        ┌──────────┬───────────┼───────────┬──────────┐
        │          │           │           │          │
        ▼          ▼           ▼           ▼          ▼
    Order     Payment      Shipping    Inventory    Event
    Types     Types        Types       Types        Types
   (8 types) (12 types)   (6 types)   (7 types)    (5 types)

A client that needs only order reading operations still depends on Payment Types, Shipping Types, Inventory Types, and Event Types—none of which it uses.

Quantifying the Problem:

Interface Methods	Avg Types per Method	Total Type Dependencies
5	2	10
15	3	45
30	3	90
50	3	150

A client using 3 methods from a 50-method interface depends on approximately 150 types, when it only needs ~9. That's 94% waste.

The 10:1 Ratio

As a rough heuristic, if a client uses less than 10% of an interface's methods, investigate immediately. This ratio suggests the interface is severely too fat for that particular use case and segregation should be prioritized.

Compilation Coupling: The Build-Time Tax

Unused method dependencies create compilation coupling—the requirement that components be recompiled together even when their actual runtime behavior is unrelated.

The Mechanics of Compilation Coupling:

In compiled languages (Java, C#, TypeScript with strict mode), when an interface signature changes, all code that depends on that interface must be recompiled. The compiler needs to verify that dependent code is still compatible with the new interface definition.

For fat interfaces, this means:

A change to method M on interface I
Triggers recompilation of all classes that depend on I
Even if those classes never call method M
Even if those classes are in different modules, services, or teams

CompilationCouplingExample.ts
TypeScript
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
// ===== BEFORE: Original interface =====
interface IOrderService {
    getOrderById(orderId: string): Promise<Order>;
    getOrdersByCustomer(customerId: string): Promise<Order[]>;
    
    // Payment method - used only by CheckoutService
    processPayment(orderId: string, paymentInfo: PaymentInfo): Promise<PaymentResult>;
}
 
// ReportingService depends on IOrderService but only uses read methods
class ReportingService {
    constructor(private orderService: IOrderService) {}
    
    async generateReport(customerId: string) {
        const orders = await this.orderService.getOrdersByCustomer(customerId);
        return orders.map(o => ({ id: o.id, total: o.total }));
    }
    // Never calls processPayment
}
 
// ===== AFTER: Payment team changes processPayment signature =====
interface IOrderService {
    getOrderById(orderId: string): Promise<Order>;
    getOrdersByCustomer(customerId: string): Promise<Order[]>;
    
    // CHANGED: Added currency parameter
    processPayment(
        orderId: string, 
        paymentInfo: PaymentInfo,
        currency: Currency  // <-- NEW PARAMETER
    ): Promise<PaymentResult>;
}
 
// CONSEQUENCE: ReportingService must be recompiled.
// 
// Why? Because ReportingService's dependency on IOrderService means
// the compiler must re-verify that ReportingService is compatible
// with the new interface definition.
//
// This is true even though:
// - ReportingService never calls processPayment
// - ReportingService doesn't care about Currency
// - The actual behavior of ReportingService is unchanged
//
// In a microservices architecture, this forces redeployment of the
// reporting service because a payment interface changed.

Real-World Impact:

In large codebases, compilation coupling from fat interfaces creates several problems:

Problem	Symptom	Business Impact
Build time explosion	30-minute builds become 2-hour builds	Developer productivity loss
CI/CD pipeline congestion	Every interface change triggers full rebuilds	Slower deployments
Merge conflicts	Multiple teams modifying the same fat interface	Development friction
Test suite bloat	All tests re-run when interface changes	Longer feedback cycles
Artifact size growth	All dependent modules must be repackaged	Increased deployment times

The Cascade Effect

In one documented case, a single method signature change on a fat interface triggered the recompilation of 1,200 files across 47 modules. The original change was a one-line fix. The build took 3 hours. The lesson: unused dependencies multiply changes.

Runtime Implications of Unused Dependencies

While compilation coupling is the primary cost of unused method dependencies, runtime implications also exist, particularly in dynamic languages and certain architectural contexts.

Class Loading and Memory:

In environments like the JVM or CLR, class loading is affected by dependencies:

Classes referenced by an interface must be available at runtime
Even if never instantiated, they consume class loader resources
In modular systems (OSGi, JPMS), missing optional dependencies can cause startup failures
Reflection-based systems may eagerly load all referenced types

RuntimeDependencies.java
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
// Fat interface with diverse dependencies
public interface IOrderService {
    Order getOrderById(String orderId);
    
    // This method references the Stripe library
    StripePaymentResult processStripePayment(String orderId, StripeToken token);
    
    // This method references the S3 SDK
    S3UploadResult uploadInvoiceToS3(String orderId, byte[] pdf);
    
    // This method references Kafka
    void publishToKafka(OrderEvent event);
}
 
// A simple read-only client
public class OrderViewer {
    private final IOrderService orderService;
    
    public OrderViewer(IOrderService orderService) {
        this.orderService = orderService;
    }
    
    public Order viewOrder(String orderId) {
        return orderService.getOrderById(orderId);
    }
}
 
// RUNTIME PROBLEM:
// Even though OrderViewer only calls getOrderById(), at runtime:
// 
// 1. The JVM must load IOrderService.class
// 2. IOrderService.class references StripePaymentResult, S3UploadResult, etc.
// 3. If Stripe SDK, S3 SDK, or Kafka client JARs are not on classpath,
//    OrderViewer fails to start—even though it never uses those features.
// 
// This is why you might see:
// java.lang.NoClassDefFoundError: com/stripe/model/PaymentResult
// 
// ...in an application that has nothing to do with payments.

Dynamic Language Considerations:

In dynamic languages (Python, JavaScript, Ruby), unused method dependencies have different but equally significant effects:

Concern	Compiled Languages	Dynamic Languages
Type checking	Compile-time coupling	Linting/type-checker coupling
Missing dependencies	Link-time error	Runtime error on first call
Loading overhead	Class loading	Module imports
Documentation	Generated docs include unused methods	Same problem
IDE support	Autocomplete shows unused methods	Same problem

In TypeScript with strict mode, the compile-time guarantees apply. In plain JavaScript, the problems shift to runtime but don't disappear.

Dependency Injection Complications

When using dependency injection containers, fat interfaces complicate configuration. The container must be able to construct an implementation of the full interface, even if consumers only need a subset. This can force inclusion of heavy dependencies in lightweight services.

The Dependency Inversion Tension

Fat interfaces create an paradoxical tension with the Dependency Inversion Principle (DIP). Let's examine this tension.

The DIP Promise:

DIP states that high-level modules should not depend on low-level modules; both should depend on abstractions. The promise is that by depending on interfaces rather than concrete implementations, you achieve decoupling.

The Fat Interface Betrayal:

When the interface is fat, DIP partially achieves its goal but also creates new coupling:

Without DIP (tight coupling):
┌──────────────┐         ┌──────────────────────┐
│ ReportModule │ ──────► │ ConcreteOrderService │
└──────────────┘         │  (40 methods)        │
                         └──────────────────────┘
Problem: ReportModule coupled to concrete implementation.

With DIP + Fat Interface (partial decoupling):
┌──────────────┐       ┌─────────────────┐       ┌──────────────────────┐
│ ReportModule │ ────► │ IOrderService   │ ◄──── │ ConcreteOrderService │
└──────────────┘       │ (40 methods)    │       │  (40 methods)        │
                       └─────────────────┘       └──────────────────────┘
Partial win: ReportModule decoupled from concrete type.
New problem: ReportModule coupled to 40-method contract.

With DIP + Segregated Interfaces (full decoupling):
┌──────────────┐       ┌──────────────┐       ┌──────────────────────┐
│ ReportModule │ ────► │ IOrderReader │ ◄──── │ ConcreteOrderService │
└──────────────┘       │ (4 methods)  │       │  (implements:        │
                       └──────────────┘       │   IOrderReader,      │
                                              │   IOrderWriter,      │
                                              │   IPaymentProcessor, │
                                              │   ...)               │
                                              └──────────────────────┘
Full win: ReportModule coupled only to reading operations.

The Paradox:

Teams often implement DIP but skip interface segregation, believing that "depending on an interface" is sufficient. But a fat interface is hardly better than a god class:

Coupling Type	Direct Dependency on God Class	Dependency on Fat Interface
Implementation coupling	Yes	No ✓
Contract coupling	Yes	Yes ✗
Type coupling	Yes	Yes ✗
Change ripple	High	High ✗
Testing difficulty	High	High ✗

DIP without ISP is incomplete abstraction. You've hidden the implementation but exposed an overloaded contract.

SOLID Principles Work Together

The SOLID principles are not independent optimizations. ISP (Interface Segregation) and DIP (Dependency Inversion) must work together. DIP tells you to depend on abstractions; ISP tells you to make those abstractions focused. Applying one without the other gives partial benefits at best.

Tracing Unused Dependencies in Practice

How do you identify and quantify unused method dependencies in a real codebase? Here are diagnostic techniques used by experienced engineers:

Diagnostic Techniques

•Usage Analysis: For each interface, inventory which methods are called by which clients. Create a utilization matrix showing methods × clients. Low-fill cells indicate unused dependencies.
•IDE Navigation: In IDEs like IntelliJ or VS Code, use 'Find Usages' on each interface method. Methods with 1-2 callers across dozens of clients are candidates for segregation.
•Dependency Graphs: Tools like JDepend, NDepend, or Arkit can visualize module-level dependencies. Fat interfaces appear as high-fan-in nodes with many dependents.
•Build-Time Analysis: Track which modules rebuild when you change an interface. If changing a payment method forces rebuilding a reporting module, unused dependencies are at play.
•Code Coverage Analysis: Run integration tests that exercise specific flows. See which interface methods are never called. Combine with call graph analysis for full picture.

UtilizationAnalysis.ts
TypeScript
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
/**
 * Interface Utilization Matrix Example
 * 
 * Rows: Interface methods
 * Columns: Client classes
 * Cells: ✓ = uses method, - = unused dependency
 */
 
/*
IOrderService Method    | Report | Checkout | Notify | Analytics | Admin |
------------------------|--------|----------|--------|-----------|-------|
getOrderById            |   ✓    |    ✓     |   ✓    |     ✓     |   ✓   |
getOrdersByCustomer     |   ✓    |    -     |   -    |     ✓     |   ✓   |
searchOrders            |   ✓    |    -     |   -    |     ✓     |   ✓   |
createOrder             |   -    |    ✓     |   -    |     -     |   -   |
submitOrder             |   -    |    ✓     |   -    |     -     |   -   |
processPayment          |   -    |    ✓     |   -    |     -     |   -   |
refundPayment           |   -    |    -     |   -    |     -     |   ✓   |
sendConfirmation        |   -    |    ✓     |   ✓    |     -     |   -   |
sendShippingNotify      |   -    |    -     |   ✓    |     -     |   -   |
getOrderStatistics      |   -    |    -     |   -    |     ✓     |   ✓   |
generateSalesReport     |   -    |    -     |   -    |     ✓     |   -   |
bulkUpdateStatus        |   -    |    -     |   -    |     -     |   ✓   |
------------------------|--------|----------|--------|-----------|-------|
Methods Used            |  3/12  |   5/12   |  3/12  |    4/12   |  6/12 |
Unused Dependencies     |  75%   |   58%    |  75%   |    67%    |  50%  |
 
Analysis:
- ReportingService: 75% unused dependencies — strong candidate for IOrderReader
- NotifyService: 75% unused deps — needs only IOrderNotifier, IOrderReader
- CheckoutService: 58% unused deps — needs IOrderWriter, IPaymentProcessor
- Average unused dependency rate: 65%
 
This matrix reveals that the 12-method interface should be split into
approximately 4 focused interfaces, each serving a distinct role.
*/

The Utilization Threshold

A healthy interface has > 80% utilization by its clients. If most clients use < 50% of an interface's methods, the interface is definitively too fat. Use this threshold to prioritize refactoring efforts.

The Cognitive Cost of Unused Dependencies

Beyond compilation and runtime, unused method dependencies impose a significant cognitive cost on developers working with fat interfaces.

The Surface Area Problem:

When a developer encounters an interface, they must understand it sufficiently to use it correctly. For a 5-method interface, this is trivial. For a 40-method interface where they need only 3 methods, they face:

Scanning 40 method signatures to find the 3 they need
Reading documentation for irrelevant methods
Potentially confusing similar methods from different domains
Cross-referencing types they don't care about
Understanding preconditions and postconditions for the full interface

Time Studies:

Research on programmer cognition suggests:

Interface Size	Time to Understand (first encounter)	Time to Find Needed Method
5 methods	5-10 minutes	2-3 minutes
15 methods	20-30 minutes	8-10 minutes
40 methods	60-90 minutes	20-30 minutes

The relationship is not linear—cognitive load increases superlinearly with interface size.

Mistakes from Cognitive Overload:

Fat interfaces increase the probability of usage errors:

Calling the wrong method: updateOrder vs modifyOrder vs patchOrder—which one?
Missing preconditions: A method deep in the interface list may have preconditions that are easy to overlook
Incorrect parameter ordering: In a fat interface, similar methods may have subtly different parameter orders
Resource leaks: Cleanup methods may be lost in the noise of a large interface
Thread safety confusion: Some methods may be thread-safe while others aren't, but this gets lost in a 40-method list

40-Method IOrderService

•Overwhelming when first opened
•Difficult to find needed methods
•Easy to call wrong variant
•Documentation becomes a wall of text
•Autocomplete suggests 40 options
•Code reviews miss interface misuse

5-Method IOrderReader

•Immediately understandable
•All methods relevant to task
•Obvious which method to use
•Documentation is concise
•Autocomplete shows only options
•Misuse is immediately visible

The Onboarding Tax

New team members pay the highest cognitive cost. They haven't developed the pattern-matching intuition to skip irrelevant methods. A codebase full of fat interfaces dramatically slows onboarding. The cleaner alternative—focused interfaces—lets new developers become productive faster.

Summary: The Hidden Tax of Unused Dependencies

Unused method dependencies are the core pathology of fat interfaces—the mechanism by which interface obesity damages software systems.

Key Takeaways

•Dependencies are transitive — Depending on an interface means depending on every type it references, even types you never use.
•Five categories of unused dependencies — Type dependencies, method signatures, exceptions, documentation, and conceptual burden all create coupling.
•Compilation coupling multiplies change — A single method change can trigger recompilation of hundreds of unrelated files.
•Runtime implications vary by platform — Class loading, missing JARs, and module systems all suffer from unused dependency bloat.
•DIP without ISP is incomplete — Depending on abstractions helps, but fat abstractions still create coupling.
•Utilization analysis reveals problems — If clients use < 50% of methods, the interface is too fat.
•Cognitive cost is real — Fat interfaces slow down development, increase errors, and hurt onboarding.

What's Next:

Now that we understand how unused method dependencies create coupling, the next page examines the implementation burden—what happens when a class must implement a fat interface, dealing with methods that don't make sense for its specific purpose.

Page Complete

You now understand how unused method dependencies create hidden coupling throughout a codebase. From compilation cascades to cognitive overload, these phantom dependencies exact a tax on every team that touches the fat interface. Next, we'll explore what implementers face when forced to implement interfaces larger than their needs.

2 / 4

Loading learning content...

System Design (LLD)Interface Segregation Principle

The Fat Interfaces Problem

LevelIntermediate

Duration60 mins

TopicInterface Segregation Principle

2 / 4

Unused Method Dependencies

The Dependencies You Never Asked For

"But I just want to drive it for three days," you protest.

"Doesn't matter. The car comes as a complete package. You depend on all of it."

What You Will Learn

Understanding Dependency Mechanics

To understand unused method dependencies, we must first understand what it means for code to "depend on" an interface.

What Is a Dependency?

In software, a dependency exists when one code element (the dependent) references another code element (the dependency). This reference can be:

Explicit: Importing a type, calling a method, instantiating a class
Implicit: Relying on behavior, expecting certain invariants

The Transitive Nature of Dependencies:

Dependencies are transitive. If A depends on B, and B depends on C, then A indirectly depends on C. Changes to C can ripple through B to affect A.

DependencyChain.ts
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
// Dependency chain example
 
// C: The leaf dependency
interface PaymentResult {
    transactionId: string;
    status: 'success' | 'failed' | 'pending';
    errorMessage?: string;
}
 
// B: Depends on C (PaymentResult)
interface IOrderService {
    // This method signature creates a dependency on PaymentResult
    processPayment(orderId: string): Promise<PaymentResult>;
    
    // Even if you never call processPayment, if you depend on
    // IOrderService, you transitively depend on PaymentResult
    
    getOrderById(orderId: string): Promise<Order>;
}
 
// A: Depends on B (IOrderService), therefore transitively depends on C
class OrderReporter {
    constructor(private orderService: IOrderService) {}
    
    async generateReport(orderId: string) {
        // Only uses getOrderById
        const order = await this.orderService.getOrderById(orderId);
        return this.formatReport(order);
    }
    
    // OrderReporter never calls processPayment.
    // Yet it depends on PaymentResult because IOrderService references it.
    // If PaymentResult changes, OrderReporter must be recompiled.
}

The Phantom Dependency Problem

Categories of Unused Method Dependencies

Unused method dependencies manifest in several distinct forms, each with its own characteristics and impact on system architecture:

Five Categories of Unused Dependencies

•Type Dependencies: The interface references types (as parameters or return values) that the client never touches. Example: IOrderService references ShippingLabel, but the reporting client never deals with shipping.
•Method Signature Dependencies: The client must understand method signatures it never calls. Changes to those signatures require recompilation. Example: processPayment(orderId, amount) changes to processPayment(orderId, amount, currency), affecting all IOrderService consumers.
•Exception Dependencies: The interface declares exceptions that methods might throw. Clients depending on the interface implicitly depend on those exception types. Example: throws PaymentDeclinedException on a payment method creates a dependency even for non-payment clients.
•Documentation Dependencies: In strongly-typed languages, documentation/annotations on unused methods can create tooling dependencies. In some IDEs, documentation generation includes all interface methods.
•Conceptual Dependencies: Developers must understand the unused methods to work with the interface effectively. This cognitive load slows development and increases error risk.

Visualizing the Dependency Web:

Consider a fat IOrderService with 30 methods. Each method may reference 2-3 types (parameters, return types, exceptions). The interface creates a dependency graph:

                          IOrderService
                               │
        ┌──────────┬───────────┼───────────┬──────────┐
        │          │           │           │          │
        ▼          ▼           ▼           ▼          ▼
    Order     Payment      Shipping    Inventory    Event
    Types     Types        Types       Types        Types
   (8 types) (12 types)   (6 types)   (7 types)    (5 types)

A client that needs only order reading operations still depends on Payment Types, Shipping Types, Inventory Types, and Event Types—none of which it uses.

Quantifying the Problem:

Interface Methods	Avg Types per Method	Total Type Dependencies
5	2	10
15	3	45
30	3	90
50	3	150

A client using 3 methods from a 50-method interface depends on approximately 150 types, when it only needs ~9. That's 94% waste.

The 10:1 Ratio

Compilation Coupling: The Build-Time Tax

Unused method dependencies create compilation coupling—the requirement that components be recompiled together even when their actual runtime behavior is unrelated.

The Mechanics of Compilation Coupling:

For fat interfaces, this means:

A change to method M on interface I
Triggers recompilation of all classes that depend on I
Even if those classes never call method M
Even if those classes are in different modules, services, or teams

CompilationCouplingExample.ts
TypeScript
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
// ===== BEFORE: Original interface =====
interface IOrderService {
    getOrderById(orderId: string): Promise<Order>;
    getOrdersByCustomer(customerId: string): Promise<Order[]>;
    
    // Payment method - used only by CheckoutService
    processPayment(orderId: string, paymentInfo: PaymentInfo): Promise<PaymentResult>;
}
 
// ReportingService depends on IOrderService but only uses read methods
class ReportingService {
    constructor(private orderService: IOrderService) {}
    
    async generateReport(customerId: string) {
        const orders = await this.orderService.getOrdersByCustomer(customerId);
        return orders.map(o => ({ id: o.id, total: o.total }));
    }
    // Never calls processPayment
}
 
// ===== AFTER: Payment team changes processPayment signature =====
interface IOrderService {
    getOrderById(orderId: string): Promise<Order>;
    getOrdersByCustomer(customerId: string): Promise<Order[]>;
    
    // CHANGED: Added currency parameter
    processPayment(
        orderId: string, 
        paymentInfo: PaymentInfo,
        currency: Currency  // <-- NEW PARAMETER
    ): Promise<PaymentResult>;
}
 
// CONSEQUENCE: ReportingService must be recompiled.
// 
// Why? Because ReportingService's dependency on IOrderService means
// the compiler must re-verify that ReportingService is compatible
// with the new interface definition.
//
// This is true even though:
// - ReportingService never calls processPayment
// - ReportingService doesn't care about Currency
// - The actual behavior of ReportingService is unchanged
//
// In a microservices architecture, this forces redeployment of the
// reporting service because a payment interface changed.

Real-World Impact:

In large codebases, compilation coupling from fat interfaces creates several problems:

Problem	Symptom	Business Impact
Build time explosion	30-minute builds become 2-hour builds	Developer productivity loss
CI/CD pipeline congestion	Every interface change triggers full rebuilds	Slower deployments
Merge conflicts	Multiple teams modifying the same fat interface	Development friction
Test suite bloat	All tests re-run when interface changes	Longer feedback cycles
Artifact size growth	All dependent modules must be repackaged	Increased deployment times

The Cascade Effect

Runtime Implications of Unused Dependencies

While compilation coupling is the primary cost of unused method dependencies, runtime implications also exist, particularly in dynamic languages and certain architectural contexts.

Class Loading and Memory:

In environments like the JVM or CLR, class loading is affected by dependencies:

Classes referenced by an interface must be available at runtime
Even if never instantiated, they consume class loader resources
In modular systems (OSGi, JPMS), missing optional dependencies can cause startup failures
Reflection-based systems may eagerly load all referenced types

RuntimeDependencies.java
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
// Fat interface with diverse dependencies
public interface IOrderService {
    Order getOrderById(String orderId);
    
    // This method references the Stripe library
    StripePaymentResult processStripePayment(String orderId, StripeToken token);
    
    // This method references the S3 SDK
    S3UploadResult uploadInvoiceToS3(String orderId, byte[] pdf);
    
    // This method references Kafka
    void publishToKafka(OrderEvent event);
}
 
// A simple read-only client
public class OrderViewer {
    private final IOrderService orderService;
    
    public OrderViewer(IOrderService orderService) {
        this.orderService = orderService;
    }
    
    public Order viewOrder(String orderId) {
        return orderService.getOrderById(orderId);
    }
}
 
// RUNTIME PROBLEM:
// Even though OrderViewer only calls getOrderById(), at runtime:
// 
// 1. The JVM must load IOrderService.class
// 2. IOrderService.class references StripePaymentResult, S3UploadResult, etc.
// 3. If Stripe SDK, S3 SDK, or Kafka client JARs are not on classpath,
//    OrderViewer fails to start—even though it never uses those features.
// 
// This is why you might see:
// java.lang.NoClassDefFoundError: com/stripe/model/PaymentResult
// 
// ...in an application that has nothing to do with payments.

Dynamic Language Considerations:

In dynamic languages (Python, JavaScript, Ruby), unused method dependencies have different but equally significant effects:

Concern	Compiled Languages	Dynamic Languages
Type checking	Compile-time coupling	Linting/type-checker coupling
Missing dependencies	Link-time error	Runtime error on first call
Loading overhead	Class loading	Module imports
Documentation	Generated docs include unused methods	Same problem
IDE support	Autocomplete shows unused methods	Same problem

In TypeScript with strict mode, the compile-time guarantees apply. In plain JavaScript, the problems shift to runtime but don't disappear.

Dependency Injection Complications

The Dependency Inversion Tension

Fat interfaces create an paradoxical tension with the Dependency Inversion Principle (DIP). Let's examine this tension.

The DIP Promise:

The Fat Interface Betrayal:

When the interface is fat, DIP partially achieves its goal but also creates new coupling:

Without DIP (tight coupling):
┌──────────────┐         ┌──────────────────────┐
│ ReportModule │ ──────► │ ConcreteOrderService │
└──────────────┘         │  (40 methods)        │
                         └──────────────────────┘
Problem: ReportModule coupled to concrete implementation.

With DIP + Fat Interface (partial decoupling):
┌──────────────┐       ┌─────────────────┐       ┌──────────────────────┐
│ ReportModule │ ────► │ IOrderService   │ ◄──── │ ConcreteOrderService │
└──────────────┘       │ (40 methods)    │       │  (40 methods)        │
                       └─────────────────┘       └──────────────────────┘
Partial win: ReportModule decoupled from concrete type.
New problem: ReportModule coupled to 40-method contract.

With DIP + Segregated Interfaces (full decoupling):
┌──────────────┐       ┌──────────────┐       ┌──────────────────────┐
│ ReportModule │ ────► │ IOrderReader │ ◄──── │ ConcreteOrderService │
└──────────────┘       │ (4 methods)  │       │  (implements:        │
                       └──────────────┘       │   IOrderReader,      │
                                              │   IOrderWriter,      │
                                              │   IPaymentProcessor, │
                                              │   ...)               │
                                              └──────────────────────┘
Full win: ReportModule coupled only to reading operations.

The Paradox:

Teams often implement DIP but skip interface segregation, believing that "depending on an interface" is sufficient. But a fat interface is hardly better than a god class:

Coupling Type	Direct Dependency on God Class	Dependency on Fat Interface
Implementation coupling	Yes	No ✓
Contract coupling	Yes	Yes ✗
Type coupling	Yes	Yes ✗
Change ripple	High	High ✗
Testing difficulty	High	High ✗

DIP without ISP is incomplete abstraction. You've hidden the implementation but exposed an overloaded contract.

SOLID Principles Work Together

Tracing Unused Dependencies in Practice

How do you identify and quantify unused method dependencies in a real codebase? Here are diagnostic techniques used by experienced engineers:

Diagnostic Techniques

•Usage Analysis: For each interface, inventory which methods are called by which clients. Create a utilization matrix showing methods × clients. Low-fill cells indicate unused dependencies.
•IDE Navigation: In IDEs like IntelliJ or VS Code, use 'Find Usages' on each interface method. Methods with 1-2 callers across dozens of clients are candidates for segregation.
•Dependency Graphs: Tools like JDepend, NDepend, or Arkit can visualize module-level dependencies. Fat interfaces appear as high-fan-in nodes with many dependents.
•Build-Time Analysis: Track which modules rebuild when you change an interface. If changing a payment method forces rebuilding a reporting module, unused dependencies are at play.
•Code Coverage Analysis: Run integration tests that exercise specific flows. See which interface methods are never called. Combine with call graph analysis for full picture.

UtilizationAnalysis.ts
TypeScript
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
/**
 * Interface Utilization Matrix Example
 * 
 * Rows: Interface methods
 * Columns: Client classes
 * Cells: ✓ = uses method, - = unused dependency
 */
 
/*
IOrderService Method    | Report | Checkout | Notify | Analytics | Admin |
------------------------|--------|----------|--------|-----------|-------|
getOrderById            |   ✓    |    ✓     |   ✓    |     ✓     |   ✓   |
getOrdersByCustomer     |   ✓    |    -     |   -    |     ✓     |   ✓   |
searchOrders            |   ✓    |    -     |   -    |     ✓     |   ✓   |
createOrder             |   -    |    ✓     |   -    |     -     |   -   |
submitOrder             |   -    |    ✓     |   -    |     -     |   -   |
processPayment          |   -    |    ✓     |   -    |     -     |   -   |
refundPayment           |   -    |    -     |   -    |     -     |   ✓   |
sendConfirmation        |   -    |    ✓     |   ✓    |     -     |   -   |
sendShippingNotify      |   -    |    -     |   ✓    |     -     |   -   |
getOrderStatistics      |   -    |    -     |   -    |     ✓     |   ✓   |
generateSalesReport     |   -    |    -     |   -    |     ✓     |   -   |
bulkUpdateStatus        |   -    |    -     |   -    |     -     |   ✓   |
------------------------|--------|----------|--------|-----------|-------|
Methods Used            |  3/12  |   5/12   |  3/12  |    4/12   |  6/12 |
Unused Dependencies     |  75%   |   58%    |  75%   |    67%    |  50%  |
 
Analysis:
- ReportingService: 75% unused dependencies — strong candidate for IOrderReader
- NotifyService: 75% unused deps — needs only IOrderNotifier, IOrderReader
- CheckoutService: 58% unused deps — needs IOrderWriter, IPaymentProcessor
- Average unused dependency rate: 65%
 
This matrix reveals that the 12-method interface should be split into
approximately 4 focused interfaces, each serving a distinct role.
*/

The Utilization Threshold

The Cognitive Cost of Unused Dependencies

Beyond compilation and runtime, unused method dependencies impose a significant cognitive cost on developers working with fat interfaces.

The Surface Area Problem:

Scanning 40 method signatures to find the 3 they need
Reading documentation for irrelevant methods
Potentially confusing similar methods from different domains
Cross-referencing types they don't care about
Understanding preconditions and postconditions for the full interface

Time Studies:

Research on programmer cognition suggests:

Interface Size	Time to Understand (first encounter)	Time to Find Needed Method
5 methods	5-10 minutes	2-3 minutes
15 methods	20-30 minutes	8-10 minutes
40 methods	60-90 minutes	20-30 minutes

The relationship is not linear—cognitive load increases superlinearly with interface size.

Mistakes from Cognitive Overload:

Fat interfaces increase the probability of usage errors:

Calling the wrong method: updateOrder vs modifyOrder vs patchOrder—which one?
Missing preconditions: A method deep in the interface list may have preconditions that are easy to overlook
Incorrect parameter ordering: In a fat interface, similar methods may have subtly different parameter orders
Resource leaks: Cleanup methods may be lost in the noise of a large interface
Thread safety confusion: Some methods may be thread-safe while others aren't, but this gets lost in a 40-method list

40-Method IOrderService

•Overwhelming when first opened
•Difficult to find needed methods
•Easy to call wrong variant
•Documentation becomes a wall of text
•Autocomplete suggests 40 options
•Code reviews miss interface misuse

5-Method IOrderReader

•Immediately understandable
•All methods relevant to task
•Obvious which method to use
•Documentation is concise
•Autocomplete shows only options
•Misuse is immediately visible

The Onboarding Tax

Summary: The Hidden Tax of Unused Dependencies

Unused method dependencies are the core pathology of fat interfaces—the mechanism by which interface obesity damages software systems.

Key Takeaways

•Dependencies are transitive — Depending on an interface means depending on every type it references, even types you never use.
•Five categories of unused dependencies — Type dependencies, method signatures, exceptions, documentation, and conceptual burden all create coupling.
•Compilation coupling multiplies change — A single method change can trigger recompilation of hundreds of unrelated files.
•Runtime implications vary by platform — Class loading, missing JARs, and module systems all suffer from unused dependency bloat.
•DIP without ISP is incomplete — Depending on abstractions helps, but fat abstractions still create coupling.
•Utilization analysis reveals problems — If clients use < 50% of methods, the interface is too fat.
•Cognitive cost is real — Fat interfaces slow down development, increase errors, and hurt onboarding.

What's Next:

Page Complete

2 / 4