Fat Interfaces Problem - Learning Module

Loading content...

0/246

Change Propagation Issues

The Butterfly Effect of Interface Changes

A butterfly flaps its wings in Tokyo, and three weeks later there's a hurricane in Miami. Chaos theory's famous metaphor describes how small perturbations in complex systems can cascade into massive, unpredictable effects.

Fat interfaces create an analogous phenomenon in software: a developer adds an optional parameter to one method, and suddenly 47 files need updating, 3 teams must coordinate, 2 deployment pipelines break, and the quarterly release is at risk.

This is the change propagation problem of fat interfaces—and it's one of the most practically damaging consequences of interface obesity.

What You Will Learn

By the end of this page, you will understand how changes to fat interfaces propagate through systems, why seemingly minor modifications cascade into major disruptions, and how to analyze and predict the blast radius of interface changes. You will see concrete examples of how segregated interfaces contain change impact.

Understanding Change Propagation

What Is Change Propagation?

Change propagation refers to the phenomenon where a modification to one part of a system requires modifications to other parts. It's a fundamental property of software: components that depend on each other must be kept in sync.

The Propagation Chain:

Change Origin (Interface Method)
        │
        ▼
Direct Dependents (classes that implement or use the interface)
        │
        ▼
Transitive Dependents (code that depends on direct dependents)
        │
        ▼
Build Artifacts (compiled modules, packages)
        │
        ▼
Deployment Units (services, applications)
        │
        ▼
Operational Impact (runtime behavior, monitoring, alerts)

Each level amplifies the change. A one-line interface modification can affect hundreds of files by the time it reaches deployment.

Change Propagation in Well-Designed Systems:

In systems with properly segregated interfaces, change propagation is contained:

A method change affects only clients that use that method
Only the specific interface containing the method changes
Implementations of other interfaces are unaffected
Deployment is limited to affected services

Change Propagation with Fat Interfaces:

In systems with fat interfaces, change propagation explodes:

A method change affects ALL clients of the entire interface
Every implementation must be checked/updated
Every mock must be updated
Every dependent module recompiles
Deployments span many services

The difference isn't linear—it's often exponential.

The Coupling Multiplier

Fat interfaces are coupling multipliers. They tie together components that have no logical relationship, forcing them to change together. A payment method signature change triggers redeployment of a completely unrelated reporting service—not because reporting uses payments, but because both depend on the same fat interface.

Anatomy of a Propagating Change

Let's trace a real change through a fat interface to see propagation in action.

The Scenario:

The payment team needs to add multi-currency support. The existing method:

processPayment(orderId: string, amount: number): Promise<PaymentResult>

Must become:

processPayment(orderId: string, amount: number, currency: Currency): Promise<PaymentResult>

ChangePropagationTrace.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
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
// STEP 1: The change originates in IOrderService (fat interface with 30 methods)
interface IOrderService {
    // ... 20 read/write methods
    
    // CHANGING THIS METHOD
    processPayment(orderId: string, amount: number, currency: Currency): Promise<PaymentResult>;
    
    // ... 9 more methods
}
 
// STEP 2: All implementations must update
// Even implementations that never actually process payments!
 
// Implementation 1: Full service - needs the change
class OrderServiceImpl implements IOrderService {
    processPayment(orderId: string, amount: number, currency: Currency) {
        // Actually uses the new currency parameter
        return this.paymentGateway.charge(amount, currency);
    }
}
 
// Implementation 2: Read-only reporting - doesn't need the change, but must update
class ReadOnlyOrderProxy implements IOrderService {
    processPayment(orderId: string, amount: number, currency: Currency) { // Added currency
        throw new Error("Read-only proxy cannot process payments");
        // Still throws - but signature must match interface
    }
}
 
// Implementation 3: Test mock - doesn't need the change, but must update
class MockOrderService implements IOrderService {
    processPayment(orderId: string, amount: number, currency: Currency) { // Added currency
        return Promise.resolve({ success: true, mockData: true });
        // Ignores currency entirely
    }
}
 
// STEP 3: All mock factories must update
const createMockOrderService = (): jest.Mocked<IOrderService> => ({
    // ... 20 other mock methods
    processPayment: jest.fn((orderId, amount, currency) => // Added currency
        Promise.resolve({ success: true })),
    // ... 9 more mock methods
});
 
// STEP 4: All tests that mock the interface must update
describe('ReportingService', () => {
    let mockOrderService: jest.Mocked<IOrderService>;
    
    beforeEach(() => {
        mockOrderService = {
            // Even though ReportingService never calls processPayment,
            // we must update the mock signature
            processPayment: jest.fn(),  // Type error until we add currency param
            // ... all other methods
        };
    });
});
 
// STEP 5: Integration tests must update
describe('Order Integration Tests', () => {
    it('processes order end-to-end', async () => {
        // Even tests for order creation must use the new signature
        // if they construct mock implementations
    });
});

The Propagation Tally:

For this single method change:

Category	Files Affected	Time Required
Interface definition	1	5 min
Full implementation	3	2 hours
Stub implementations	7	1 hour
Mock factories	12	1 hour
Test files	45	3 hours
Build configurations	4	30 min
Total	72 files	7.5 hours

For a segregated interface (e.g., IPaymentProcessor with 3 methods):

Category	Files Affected	Time Required
Interface definition	1	5 min
Implementations	3	2 hours
Mock factories	3	20 min
Test files	8	1 hour
Total	15 files	3.5 hours

The fat interface caused 5x more files to change and doubled the work time.

The Hidden Time Cost

The time estimates above assume you know all the affected files. In practice, you discover affected files as the compiler complains. Each discovery interrupts your flow, requires context switching, and adds frustration. The psychological cost compounds the time cost.

Types of Changes That Propagate

Different types of interface changes propagate differently. Understanding this helps predict the blast radius of proposed modifications.

Change Types and Propagation Characteristics
Change Type	Propagation Scope	Breaking?	Mitigation Difficulty
Add new method	All implementations	Yes	Medium - implementations must add method
Remove method	All callers + implementations	Yes	High - must find and remove all usages
Change return type	All callers + implementations	Yes	High - callers expect old type
Add required parameter	All callers + implementations	Yes	Very High - every call site updates
Add optional parameter	All implementations	Partial	Medium - implementations update, callers optional
Change exception types	All callers (if checked)	Yes	Medium - catch blocks must update
Rename method	All callers + implementations	Yes	Medium - mechanical but widespread
Change parameter types	All callers + implementations	Yes	High - call sites may need logic changes

The Fat Interface Amplifier:

For each change type, the fat interface multiplies impact:

Method addition: Instead of touching 3 focused implementations, you touch 15 fat-interface implementations (most adding stubs).
Parameter change: Instead of updating 10 call sites in the payment module, you update 200 mocks across the entire codebase.
Return type change: Instead of fixing 5 callers, you fix 50, plus 30 implementations that don't even return real values.

The Cascade Effect:

With fat interfaces, changes often cascade into more changes:

1. Add currency parameter to processPayment
   │
   ├── 2. Update Currency type to be more comprehensive
   │      │
   │      └── 3. Currency now requires exchange rate source
   │             │
   │             └── 4. ExchangeRateService interface touched
   │
   └── 5. Mock factories need Currency generation
          │
          └── 6. Test utility library updated
                 │
                 └── 7. All tests importing utility recompile

What started as one method change has become a system-wide refactoring session.

Predicting Blast Radius

Before making an interface change, run a dependency analysis: 'Find all files that import this interface.' The count indicates your blast radius. For fat interfaces, this count is always larger than necessary. For segregated interfaces, the count matches actual usage.

Build and Deployment Cascade

Change propagation doesn't stop at source files—it extends to builds and deployments.

Build Impact:

Modern build systems track dependencies to enable incremental compilation. When a file changes, only files that depend on it recompile. But fat interfaces create dense dependency graphs:

┌─────────────────┐
│  IOrderService  │ ← Fat interface: 30 methods
└────────┬────────┘
         │
    ╔════╧════╗ ← 50 files depend on this interface
    ║   ???   ║
    ╚════╤════╝
         │
┌────────┴────────┐
│  All 50 files   │ ← All recompile when interface changes
│  recompile      │
└─────────────────┘

Versus segregated interfaces:

┌──────────────┐   ┌──────────────┐   ┌──────────────┐
│ IOrderReader │   │IPaymentProc  │   │IOrderNotify  │
└──────┬───────┘   └──────┬───────┘   └──────┬───────┘
       │                  │                  │
   10 files           8 files           7 files

Changing IPaymentProcessor affects only 8 files, not 50.

Deployment Impact:

In microservices architectures, fat interfaces have particularly severe deployment consequences:

Architecture Style	Fat Interface Impact	Segregated Interface Impact
Monolith	Full recompile + redeploy	Full recompile + redeploy
Modular Monolith	Affected modules recompile	Only related module recompiles
Microservices (shared lib)	All services update library	Only relevant services update
Microservices (per-service)	Interface duplicated everywhere	Clean service boundaries

The Shared Library Problem:

A common pattern is packaging interfaces in shared libraries:

shared-interfaces.jar (or npm package)
├── IOrderService (30 methods)
├── IUserService (20 methods)
└── IInventoryService (15 methods)

Services depending on shared-interfaces:
├── order-service
├── payment-service
├── shipping-service
├── reporting-service
├── analytics-service
└── admin-service

When IOrderService changes, shared-interfaces publishes a new version. All 6 services must update to the new version—even if only order-service actually uses the changed method.

With segregated interfaces:

order-reading.jar    → used by: reporting-service, analytics-service
payment.jar          → used by: payment-service, order-service
shipping.jar         → used by: shipping-service, order-service

Changing payment.jar affects only 2 services.

Deployment Coordination Hell

When a fat interface change requires deploying 6 services simultaneously, you need deployment coordination—rollback plans, database migration timing, cross-service version compatibility. A segregated interface change affecting 2 services is simpler by an order of magnitude.

Version Compatibility and Interface Evolution

Fat interfaces create severe version compatibility challenges that constrain how systems can evolve.

The Versioning Dilemma:

When an interface changes, consumers must update to the new version. But with fat interfaces, determining compatibility is difficult:

IOrderService v1.0.0 → v1.1.0

What changed?
- Added: new analytics method
- Changed: payment method signature

For ReportingService (uses only read methods):
- Doesn't need analytics → but must accept it
- Doesn't use payment → but signature changed
- Is v1.1.0 compatible? Technically yes, but it must rebuild.

For PaymentService (uses payment methods):
- Needs the new signature
- Must update

For AnalyticsService (wants new analytics):
- Wants the new method
- Must update

Result: All services update, even those unaffected by the changes.

VersionCompatibility.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
// Semantic Versioning with Fat Interfaces
 
/**
 * IOrderService version history:
 * 
 * v1.0.0 - Initial release (25 methods)
 * v1.1.0 - Added getOrderMetrics() - analytics feature
 * v1.2.0 - Changed processPayment() signature - currency support
 * v1.3.0 - Added archiveOrder() - archival feature
 * v1.4.0 - Deprecated getOrderHistory(), added getOrderAuditLog()
 * v2.0.0 - Removed getOrderHistory() - breaking change
 * 
 * Semantic versioning says:
 * - MINOR bumps (1.1, 1.2, 1.3) should be backward compatible
 * - MAJOR bumps (2.0) indicate breaking changes
 * 
 * But wait: adding a method IS a breaking change for implementations!
 * 
 * v1.1.0 adds getOrderMetrics():
 * - Consumers: Compatible (don't have to call new method)
 * - Implementations: Breaking! (must add new method)
 * 
 * So is v1.1.0 a minor or major version?
 * - For consumers: minor
 * - For implementers: major
 * 
 * Fat interface versioning is inherently confused.
 */
 
// With fat interfaces, you often see:
// - Premature major version bumps (v47.0.0 for a 3-year-old library)
// - Version conflicts between services
// - Dependency hell trying to align versions
 
// With segregated interfaces:
// IOrderReader: changes rarely, stable at v1.x
// IPaymentProcessor: v3.x due to payment industry changes
// IOrderArchive: new interface, at v1.0
// 
// Each interface evolves at its own pace.
// Services consume specific interfaces at specific versions.
// No forced upgrades for unrelated changes.

The Diamond Dependency Problem:

In complex dependency graphs, fat interfaces cause version conflicts:

      ┌──────────────────┐
      │  order-service   │
      └────────┬─────────┘
          needs IOrderService v2.0
               │
      ┌────────┴─────────┐
      │                  │
      ▼                  ▼
┌───────────┐      ┌───────────┐
│ lib-a     │      │ lib-b     │
│ uses v1.0 │      │ uses v2.0 │
└─────┬─────┘      └─────┬─────┘
      │                  │
      └─────────┬────────┘
                ▼
         ┌───────────┐
         │ shared-   │
         │ interfaces│
         │ v??? CONFLICT │
         └───────────┘

Both lib-a and lib-b are in the dependency tree, but they need different versions. Classic diamond dependency.

With segregated interfaces, this rarely happens—each library depends on only the interfaces it needs, and those interfaces evolve independently.

Interface Stability

Small, focused interfaces tend to be more stable. When an interface has one job (reading orders), it only changes when that job changes. Fat interfaces change whenever any of their many jobs change. Interface stability is a direct result of proper segregation.

Measuring and Predicting Change Impact

Experienced engineers develop metrics and techniques to predict change propagation before it happens.

Change Impact Metrics

•Fan-Out Count: How many files import this interface? Higher counts mean wider propagation.
•Afferent Coupling (Ca): Number of classes outside the package that depend on classes within. High Ca for interfaces indicates wide impact.
•Change Impact Set (CIS): Given a change, the set of all files that must be modified. Analyzable statically.
•Implementation Count: Number of classes implementing the interface. Each must be updated for method additions.
•Mock Count: Number of test mocks for the interface. Often the largest category of affected files.

ChangeImpactAnalysis.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
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
/**
 * Example Change Impact Analysis
 * 
 * Interface: IOrderService (fat interface)
 * Proposed Change: Add async updateOrderStatus(orderId, status, reason)
 */
 
// METRIC 1: Fan-Out Count
const fanOutAnalysis = {
    interface: 'IOrderService',
    totalImports: 156,  // 156 files import this interface
    categories: {
        implementations: 12,
        directClients: 45,
        testFiles: 67,
        mockFactories: 18,
        typeDefinitions: 14,
    }
};
 
// METRIC 2: Change Impact Set
const changeImpactSet = {
    definitelyAffected: [
        // Files that MUST change
        'interfaces/IOrderService.ts',        // Interface definition
        'services/OrderServiceImpl.ts',       // Primary implementation
        'services/OrderServiceV2Impl.ts',     // Alternative implementation
        'adapters/ExternalOrderAdapter.ts',   // External adapter
        // ... 9 more implementations
        'testing/MockOrderService.ts',        // Main mock
        'testing/OrderServiceTestDouble.ts',  // Test double
        // ... 16 more mocks
    ],
    likelyAffected: [
        // Files that probably need review
        'testing/__mocks__/orderService.ts',
        'e2e/helpers/mockServices.ts',
        // ... integration test helpers
    ],
    possiblyAffected: [
        // Files that might break at runtime
        'plugins/OrderStatusPlugin.ts',  // Might try to call the method
        'scripts/migrateOrders.ts',      // Utility scripts
    ],
    stats: {
        definite: 32,
        likely: 18,
        possible: 8,
        totalBlastRadius: 58,
    }
};
 
// COMPARISON: Segregated IOrderStatusManager interface
const segregatedChangeImpactSet = {
    definitelyAffected: [
        'interfaces/IOrderStatusManager.ts',
        'services/OrderStatusManagerImpl.ts',
        'testing/MockOrderStatusManager.ts',
    ],
    likelyAffected: [],
    possiblyAffected: [],
    stats: {
        definite: 3,
        likely: 0,
        possible: 0,
        totalBlastRadius: 3,
    }
};
 
// The segregated approach has 95% smaller blast radius

Using Metrics for Decision Making:

Blast Radius	Action
1-10 files	Normal development; proceed with change
11-30 files	Consider if change is necessary; plan carefully
31-75 files	Strong signal interface is too fat; consider refactoring first
75+ files	Interface urgently needs segregation; change will be very costly

Pre-Change Analysis:

Before making any interface change:

Run impact analysis to count affected files
Categorize by: implementation, mock, test, production code
Estimate time based on category (mocks are often mechanical, production code needs care)
Consider whether segregating the interface first would reduce future change costs
Document the blast radius for team awareness

The 5-Minute Rule

If updating all affected files takes less than 5 minutes of mechanical work, the change is manageable. If it takes hours, the interface is too coupled. Use this rule to trigger segregation conversations.

Strategies for Containing Change Propagation

Given an existing fat interface, there are strategies to contain change propagation while working toward full segregation.

Containment Strategies

•Default Method Implementations: In languages supporting it (Java 8+, C# 8+), add default implementations to interface methods. New methods don't force implementation updates.
•Optional Methods Pattern: Use Optional/nullable returns for new methods. Implementations return empty until they support the feature. Not ideal, but limits break radius.
•Extension Interfaces: Instead of modifying the fat interface, create extension interfaces. IOrderServiceExtensions inherits from IOrderService and adds new methods. Only new implementations implement the extension.
•Adapter/Facade Layer: Create thin facades that expose only what clients need. Changes to the underlying fat interface are absorbed by the facade, not propagated to all clients.
•Interface Versioning: Maintain multiple versions (IOrderServiceV1, IOrderServiceV2). Clients upgrade at their own pace. Eventually deprecate old versions.

ContainmentStrategies.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
47
48
49
50
51
52
// STRATEGY 1: Extension Interfaces
// Instead of modifying the fat interface:
 
// Original interface - don't touch
interface IOrderService {
    getOrder(id: string): Promise<Order>;
    saveOrder(order: Order): Promise<void>;
    // ... 28 other methods
}
 
// New capability added via extension
interface IOrderServiceWithAnalytics extends IOrderService {
    getOrderMetrics(dateRange: DateRange): Promise<Metrics>;
}
 
// New implementations can implement the extension
class OrderServiceWithAnalytics implements IOrderServiceWithAnalytics {
    // Implements all IOrderService methods + getOrderMetrics
}
 
// Clients that need analytics depend on the extension
class AnalyticsClient {
    constructor(private service: IOrderServiceWithAnalytics) {}
}
 
// Existing clients continue to use IOrderService - unaffected
 
// STRATEGY 2: Facade Layer
// Create focused facades for specific client needs
 
// Fat interface in the implementation layer
interface IOrderService { /* 30 methods */ }
 
// Focused facade for reporting
class OrderReportingFacade {
    constructor(private orderService: IOrderService) {}
    
    async getOrdersForReport(customerId: string): Promise<Order[]> {
        return this.orderService.getOrdersByCustomer(customerId);
    }
    
    async getOrderStatistics(range: DateRange): Promise<Statistics> {
        return this.orderService.getOrderMetrics(range);
    }
    // Only exposes 2-3 methods, not 30
}
 
// Clients depend on the facade, not the fat interface
class ReportGenerator {
    constructor(private facade: OrderReportingFacade) {}
    // Isolated from IOrderService changes that don't affect reporting
}

Containment Is Temporary

These strategies buy time, but they don't solve the underlying problem. Extension interfaces accumulate. Facades multiply. Version numbers inflate. Eventually, the fat interface must be properly segregated. Use containment to stabilize, then plan for real refactoring.

Summary: The Propagation Tax

Change propagation is perhaps the most practically damaging consequence of fat interfaces—the mechanism that turns routine modifications into cross-team, multi-day efforts.

Key Takeaways

•Changes propagate through dependency chains — A modification cascades from interface to implementations to tests to builds to deployments.
•Fat interfaces amplify blast radius — Changes affect all dependents, not just those using the changed method.
•Different change types have different propagation profiles — Adding methods affects implementations; changing signatures affects everyone.
•Builds and deployments cascade — Shared interface libraries force coordinated multi-service deployments.
•Version compatibility becomes complex — Fat interfaces conflate unrelated changes into single version bumps.
•Impact is measurable and predictable — Fan-out count, implementation count, and change impact sets quantify the problem.
•Containment strategies exist but are temporary — Extension interfaces and facades buy time but don't solve the root cause.

Module Complete:

You have now completed the module on Fat Interfaces Problem. You understand:

What fat interfaces are — bloated contracts that exceed client needs
Unused method dependencies — phantom coupling through unused interface methods
Implementation burden — the impossible choices faced by implementers
Change propagation — how modifications cascade throughout systems

Together, these four dimensions paint a complete picture of why interface obesity is a serious design flaw, not merely an aesthetic concern. The next module will explore role-based interface design—the solution to fat interface problems.

Module Complete

You now understand the full scope of the fat interfaces problem: from initial bloat to unused dependencies, from implementation burden to change propagation. You can identify fat interfaces, predict their impact, and articulate why they must be addressed. The next module shows you how to fix them through role-based interface design.