Interfaces as Abstraction - Depending on Abstractions | OneNoughtOne

0/290

System Design (HLD)Depending on Abstractions

Depending on Abstractions

LevelIntermediate

Duration75 mins

TopicDepending on Abstractions

1 / 4

Interfaces as Abstraction

The Architecture of Independence

In the annals of software engineering, few concepts have proven as transformative as the interface. What appears on the surface to be a simple language feature—a collection of method signatures without implementation—is in reality the most powerful abstraction mechanism ever devised for building large-scale software systems.

Interfaces represent a fundamental philosophical shift in how we think about software. Instead of asking "What does this object do?" we ask "What contract does this object fulfill?" This subtle reframing enables architectural patterns that would be impossible in a world of concrete dependencies.

At their core, interfaces answer a profound question: How do we build systems where components can be developed, tested, and replaced independently? The answer lies in understanding interfaces not as a programming convenience, but as the primary mechanism for achieving architectural freedom.

What You Will Master

By the end of this page, you will understand interfaces as architectural tools, not just language features. You'll learn how interfaces create abstraction layers that enable dependency inversion, facilitate testing, and provide the flexibility to swap implementations without cascading changes. You'll see why experienced architects consider interfaces the single most important tool in their design arsenal.

The Nature of Abstraction

Before we can fully appreciate interfaces, we must understand what abstraction truly means in software engineering. Abstraction is not simply "hiding details"—it is the deliberate creation of a conceptual boundary that separates what something does from how it does it.

The Philosophical Foundation:

Plato's allegory of the cave provides a useful metaphor. In Plato's cave, prisoners see only shadows on the wall—abstractions of real objects. These shadows lack detail, but they convey essential information about shape and movement. Similarly, an interface is a shadow of an implementation: it reveals the essential behavior while concealing the mechanical details.

The power of abstraction lies in this selective revelation. When you depend on an interface, you depend only on what matters for your purposes—the contract—while remaining blissfully ignorant of implementation specifics that could change.

Levels of Abstraction:

Software systems operate at multiple abstraction levels simultaneously:

Abstraction Levels in Software Systems
Level	Abstraction	Concrete Reality	What's Hidden
Hardware	Memory addresses	Physical RAM chips	Electrical signals, timing
Operating System	Files and processes	Disk sectors, CPU scheduling	Device drivers, interrupts
Language Runtime	Objects and methods	Memory allocation, garbage collection	Pointer arithmetic, heap management
Framework	Services and repositories	HTTP handlers, SQL queries	Protocol details, connection pooling
Application	Business operations	Framework components	Technical infrastructure

Interfaces as Abstraction Boundaries:

Interfaces exist at each level where we need to establish a stable contract between layers. They are not just a programming construct—they are architectural boundaries that define how components interact.

Consider what happens without proper abstraction boundaries. If module A directly uses the concrete class from module B, any change to B's implementation potentially breaks A. This creates a rigid system where changes propagate unpredictably. Interfaces break this chain of dependency by establishing a stable contract that both modules agree upon.

The Essence of Interface-Based Abstraction:

An interface represents a role that implementations fulfill. When you define an interface, you're not describing a thing—you're describing a capability. This is a crucial distinction:

A DatabaseConnection describes a thing (a connection to a database)
A DataStore describes a capability (the ability to store and retrieve data)

The capability-focused view is more powerful because it allows any implementation that provides that capability, regardless of its nature. A DataStore could be a database, a file system, an in-memory cache, or a remote API—the client code doesn't need to know or care.

The Abstraction Test

To evaluate whether an interface represents a good abstraction, ask: 'Could this interface be implemented in fundamentally different ways?' If the answer is yes, you have a genuine abstraction. If the interface is so specific that only one implementation is possible, it's just a thin wrapper around the concrete class—not a true abstraction.

Anatomy of an Interface

An interface is deceptively simple in its syntactic form, but understanding its components reveals the depth of the abstraction mechanism.

The Syntactic Elements:

In most object-oriented languages, an interface consists of:

Method Signatures — The operations that implementing classes must provide, including method names, parameter types, and return types.
Properties (in some languages) — Gettable and/or settable values that implementations must expose.
Constants (in some languages) — Immutable values associated with the interface.
Type Information — The interface name itself becomes a type that can be used in declarations, parameters, and return types.

Notably absent is any implementation. This is not an oversight—it's the entire point. The interface defines what while implementations define how.

interface_anatomy.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
// A well-designed interface demonstrates the abstraction of "message sending"
// Note: We define WHAT operations exist, not HOW they work
 
interface MessageSender {
    // Method signature: defines contract for sending messages
    send(recipient: string, message: string): Promise<SendResult>;
    
    // Method signature: defines contract for checking send status
    getStatus(messageId: string): Promise<MessageStatus>;
    
    // Method signature: batch operations for efficiency
    sendBatch(messages: Message[]): Promise<BatchResult>;
    
    // Property: read-only capability indicator
    readonly supportsRichContent: boolean;
}
 
// The interface makes NO assumptions about:
// - Whether this uses email, SMS, push notifications, or carrier pigeon
// - What network protocols are involved
// - How retries are handled
// - Where messages are queued
// - What happens during failures
 
// Each of these could be radically different implementations:
class EmailSender implements MessageSender { /* ... */ }
class SMSSender implements MessageSender { /* ... */ }
class SlackSender implements MessageSender { /* ... */ }
class MockSender implements MessageSender { /* for testing */ }

The Semantic Elements:

Beyond syntax, interfaces carry implicit semantic meaning that is equally important:

Preconditions — What must be true before a method is called (e.g., recipient must be valid).
Postconditions — What will be true after a method completes (e.g., message will be queued).
Invariants — What must always be true for any implementation (e.g., sent messages cannot be unsent).
Error Conditions — How failures are communicated (exceptions, error codes, null returns).
Behavioral Expectations — Implied behaviors like idempotency, thread safety, or eventual consistency.

These semantic elements form the contract of the interface. Syntactic compliance is verified by the compiler; semantic compliance must be maintained through discipline, documentation, and testing.

The Implicit Protocol:

Every interface implies a protocol—an expected sequence of interactions. For example, a Connection interface implies: open → use → close. A Transaction interface implies: begin → operate → commit/rollback. These protocols are part of the interface's contract even if not expressible in syntax.

The Contract Is More Than Syntax

The most common interface design mistake is focusing only on syntax while ignoring semantics. An interface can be syntactically satisfied while completely violating its intended contract. For instance, a Cache interface implementation that never actually caches anything is syntactically correct but semantically broken. Document the full contract, not just the method signatures.

Interfaces vs Abstract Classes

A perpetual question in object-oriented design is when to use interfaces versus abstract classes. Understanding the fundamental differences illuminates when each is appropriate.

The Core Distinction:

Interface = "can behave as" (capability/role)
Abstract Class = "is a kind of" (identity/category)

This distinction seems subtle but has profound implications. An interface says "I promise to provide these behaviors." An abstract class says "I am a specialized version of this thing."

The Inheritance Model:

Most languages allow a class to implement multiple interfaces but inherit from only one abstract class (single inheritance). This isn't an arbitrary limitation—it reflects the conceptual difference:

A thing can have many capabilities (multiple interfaces)
A thing can only be one kind of thing (single inheritance)

A Document class might implement Printable, Exportable, Searchable, and Versionable interfaces while extending a single PersistentEntity abstract class.

Interface Characteristics

•Pure contract — No implementation provided
•Multiple inheritance — A class can implement many interfaces
•No state — Cannot declare instance fields
•Weak coupling — Only behavioral dependency
•Role-based — Describes what something can do
•Compositional — Promotes composition over inheritance

Abstract Class Characteristics

•Partial implementation — Can provide default behavior
•Single inheritance — A class can extend one abstract class
•Has state — Can declare instance fields
•Stronger coupling — Inheritance binds more tightly
•Identity-based — Describes what something is
•Hierarchical — Promotes inheritance hierarchies

When to Choose Interface:

When defining a role that unrelated classes might fulfill
When you want maximum flexibility for implementers
When the contract is purely behavioral with no shared state
When you anticipate multiple, independent implementations
When dependency inversion is a primary goal

When to Choose Abstract Class:

When there's genuinely shared implementation among subclasses
When you want to provide sensible defaults that can be overridden
When the abstraction requires shared state
When you're defining a family of closely related types
When template method or similar patterns apply

The Hybrid Approach:

A powerful pattern combines both: define an interface for the public contract, then provide an abstract base class implementing common functionality. Clients depend on the interface (maximum flexibility), while implementers can choose to extend the base class (convenience) or implement the interface directly (maximum control).

hybrid_approach.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
35
36
37
38
39
40
41
42
43
44
45
46
// Step 1: Define the public contract as an interface
interface PaymentProcessor {
    processPayment(payment: PaymentRequest): Promise<PaymentResult>;
    refund(transactionId: string, amount: Money): Promise<RefundResult>;
    getTransactionHistory(query: TransactionQuery): Promise<Transaction[]>;
}
 
// Step 2: Provide an abstract base class with common functionality
abstract class BasePaymentProcessor implements PaymentProcessor {
    // Shared state
    protected readonly logger: Logger;
    protected readonly auditService: AuditService;
    
    constructor(logger: Logger, auditService: AuditService) {
        this.logger = logger;
        this.auditService = auditService;
    }
    
    // Template method pattern: defines the algorithm skeleton
    async processPayment(payment: PaymentRequest): Promise<PaymentResult> {
        this.logger.info('Processing payment', { payment });
        await this.validatePayment(payment);        // Abstract - must implement
        const result = await this.executePayment(payment);  // Abstract - must implement
        await this.auditService.record(payment, result);    // Shared
        return result;
    }
    
    // Abstract methods that subclasses must implement
    protected abstract validatePayment(payment: PaymentRequest): Promise<void>;
    protected abstract executePayment(payment: PaymentRequest): Promise<PaymentResult>;
    
    // Other interface methods...
    abstract refund(transactionId: string, amount: Money): Promise<RefundResult>;
    abstract getTransactionHistory(query: TransactionQuery): Promise<Transaction[]>;
}
 
// Step 3: Implementations can extend base class or implement interface directly
class StripePaymentProcessor extends BasePaymentProcessor {
    // Inherits logging, auditing, and algorithm structure
    // Only needs to provide Stripe-specific logic
}
 
class CustomPaymentProcessor implements PaymentProcessor {
    // Complete freedom - doesn't use the base class at all
    // Useful when the base class abstractions don't fit
}

The Preference for Interfaces

In dependency inversion contexts, prefer interfaces over abstract classes. Interfaces provide maximum decoupling because they carry no implementation baggage. When a client depends on an interface, it depends only on the contract—not on any base class implementation details, default behaviors, or protected methods that abstract classes might expose.

Interfaces as Dependency Boundaries

The Dependency Inversion Principle (DIP) states that high-level modules should not depend on low-level modules; both should depend on abstractions. Interfaces are the mechanism by which this inversion is achieved.

The Traditional Dependency Problem:

Consider a typical application without DIP. A ReportGenerator class needs to send reports via email. The naive approach creates a direct dependency:

traditional_dependency.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
35
// ❌ PROBLEMATIC: Direct dependency on concrete implementation
 
class GmailEmailService {
    constructor(private apiKey: string, private sender: string) {}
    
    sendEmail(to: string, subject: string, body: string): void {
        // Gmail-specific implementation
        // Uses Gmail API, handles Gmail-specific authentication
    }
}
 
class ReportGenerator {
    private emailService: GmailEmailService;  // ← Direct dependency on Gmail
    
    constructor() {
        // Hard-coded dependency creation
        this.emailService = new GmailEmailService('key123', 'reports@company.com');
    }
    
    generateAndSendReport(reportData: ReportData): void {
        const report = this.buildReport(reportData);
        this.emailService.sendEmail(
            reportData.recipient,
            'Your Report',
            report
        );
    }
}
 
// Problems with this design:
// 1. ReportGenerator is coupled to Gmail specifically
// 2. Cannot test without Gmail credentials and network
// 3. Cannot switch to different email provider
// 4. Cannot use for non-email delivery (Slack, SMS)
// 5. Changes to GmailEmailService ripple to ReportGenerator

The Interface-Based Solution:

By introducing an interface, we create a stable boundary between the high-level policy (report generation) and the low-level mechanism (email sending):

interface_based_solution.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
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
// ✅ CORRECT: Dependency on abstraction
 
// The interface lives with the high-level module (ReportGenerator)
// This is crucial - the abstraction is owned by the consumer
interface NotificationSender {
    send(recipient: string, subject: string, content: string): Promise<void>;
}
 
// High-level module depends only on the interface
class ReportGenerator {
    constructor(private notificationSender: NotificationSender) {}
    
    async generateAndSendReport(reportData: ReportData): Promise<void> {
        const report = this.buildReport(reportData);
        await this.notificationSender.send(
            reportData.recipient,
            'Your Report',
            report
        );
    }
    
    // ReportGenerator has zero knowledge of:
    // - Email, SMS, Slack, or any specific transport
    // - Network protocols or authentication
    // - Retry logic or failure handling
    // - Provider-specific quirks
}
 
// Low-level modules implement the interface
class GmailSender implements NotificationSender {
    constructor(private apiKey: string, private sender: string) {}
    
    async send(recipient: string, subject: string, content: string): Promise<void> {
        // Gmail-specific implementation
    }
}
 
class SendGridSender implements NotificationSender {
    async send(recipient: string, subject: string, content: string): Promise<void> {
        // SendGrid-specific implementation
    }
}
 
class SlackSender implements NotificationSender {
    async send(recipient: string, subject: string, content: string): Promise<void> {
        // Slack-specific implementation (recipient = channel)
    }
}
 
class MockSender implements NotificationSender {
    public sentMessages: Array<{recipient: string; subject: string; content: string}> = [];
    
    async send(recipient: string, subject: string, content: string): Promise<void> {
        this.sentMessages.push({ recipient, subject, content });
    }
}
 
// Dependency injection makes everything flexible
const prodReportGenerator = new ReportGenerator(new GmailSender(config.gmail.apiKey, config.gmail.sender));
const testReportGenerator = new ReportGenerator(new MockSender());

The Inversion Explained:

Notice what changed:

Before Inversion: ReportGenerator (high-level) → GmailEmailService (low-level)
- High-level depends on low-level details
After Inversion: ReportGenerator (high-level) → NotificationSender (interface) ← GmailSender (low-level)
- Both depend on the abstraction
- The low-level module's arrow is reversed (it now implements the interface)
- Dependencies flow toward abstractions

This is the "inversion"—we've inverted the direction of the dependency from low-level to high-level, replacing it with dependencies from both directions toward a shared abstraction.

Benefits of the Interface Boundary:

Interface Boundary Benefits

•Isolation — Changes to email provider implementation don't affect ReportGenerator
•Testability — MockSender enables fast, isolated unit tests
•Flexibility — Swap providers without changing business logic
•Extensibility — Add new notification channels without modification
•Parallel Development — Teams can work independently on each side of the interface
•Deployment Independence — Different implementations can be deployed separately

The Direction of Dependencies Matters

In a well-designed system, dependencies point toward stability. Interfaces (abstractions) are more stable than implementations because they change less frequently. By making both high-level and low-level modules depend on interfaces, you create a system where the most stable elements (abstractions) are at the center, and volatility is pushed to the edges (implementations).

Interface Design Principles

Designing effective interfaces requires more than just extracting method signatures from classes. A well-designed interface embodies principles that maximize its value as an abstraction.

Principle 1: Interface Segregation

Interfaces should be small and focused. The Interface Segregation Principle (ISP) states that clients should not be forced to depend on methods they don't use. A "fat" interface that covers many responsibilities forces implementers to provide methods irrelevant to their purpose.

Principle 2: Conceptual Unity

All methods in an interface should belong to one coherent concept. If you find yourself naming an interface UserManagerAndEmailSender, you've violated conceptual unity. Split it into focused interfaces.

Principle 3: Consumer-Driven Design

Design interfaces from the perspective of the consumer, not the implementer. Ask "What operations does the consumer need?" rather than "What can this implementation do?" This ensures the interface serves its clients rather than merely exposing implementation capabilities.

interface_design_examples.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
35
36
37
38
39
40
41
42
43
44
// ❌ POOR: Fat interface mixing concerns
interface UserService {
    createUser(data: UserData): Promise<User>;
    updateUser(id: string, data: UserData): Promise<User>;
    deleteUser(id: string): Promise<void>;
    getUserById(id: string): Promise<User>;
    getUsersByRole(role: string): Promise<User[]>;
    sendWelcomeEmail(user: User): Promise<void>;
    sendPasswordResetEmail(user: User): Promise<void>;
    validatePassword(password: string): boolean;
    hashPassword(password: string): string;
    authenticate(email: string, password: string): Promise<AuthResult>;
    generateAuthToken(user: User): string;
    invalidateAuthToken(token: string): void;
}
 
// ✅ GOOD: Segregated interfaces with single responsibilities
interface UserRepository {
    create(data: UserData): Promise<User>;
    update(id: string, data: UserData): Promise<User>;
    delete(id: string): Promise<void>;
    findById(id: string): Promise<User | null>;
    findByRole(role: string): Promise<User[]>;
}
 
interface UserNotifier {
    sendWelcomeEmail(user: User): Promise<void>;
    sendPasswordResetEmail(user: User): Promise<void>;
}
 
interface PasswordService {
    validate(password: string): ValidationResult;
    hash(password: string): string;
    verify(password: string, hash: string): boolean;
}
 
interface AuthenticationService {
    authenticate(email: string, password: string): Promise<AuthResult>;
    generateToken(user: User): string;
    invalidateToken(token: string): void;
}
 
// Each interface can now be implemented and tested independently
// Consumers depend only on what they need

Principle 4: Semantic Clarity

Interface names and method signatures should clearly communicate their purpose. Avoid generic names that don't convey meaning (doProcess, handleStuff). Use domain language that makes the interface self-documenting.

Principle 5: Minimal Coupling in Parameters

Avoid using concrete types in interface method parameters when primitives or other interfaces suffice. Each concrete type in a signature creates a dependency that reduces flexibility.

Principle 6: Appropriate Abstraction Level

Interfaces should operate at the abstraction level appropriate for their consumers. A business logic consumer shouldn't deal with database transactions; a UI consumer shouldn't deal with HTTP headers. Match the interface to its usage context.

Principle 7: Stability Through Careful Design

Once published, interfaces are expensive to change. Every change potentially breaks all implementers. Design interfaces thoughtfully, considering future needs, before committing them. Adding methods is usually safe; changing or removing them is breaking.

The Interface Stability Imperative

Treat published interfaces as contracts. In distributed systems or public APIs, interface changes can break integrations you don't control. Prefer introducing new interfaces or new methods over modifying existing ones. When changes are unavoidable, use versioning strategies (IUserServiceV2) or deprecation cycles.

Common Interface Patterns

Certain interface patterns appear repeatedly across software systems. Understanding these patterns helps you recognize opportunities to apply abstraction effectively.

Pattern 1: Repository Pattern

Abstracts data persistence, allowing business logic to work with domain objects without knowledge of storage mechanisms.

repository_pattern.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
interface OrderRepository {
    save(order: Order): Promise<Order>;
    findById(id: OrderId): Promise<Order | null>;
    findByCustomer(customerId: CustomerId): Promise<Order[]>;
    findPending(): Promise<Order[]>;
    delete(id: OrderId): Promise<void>;
}
 
// Can be implemented by:
// - PostgresOrderRepository (SQL)
// - MongoOrderRepository (NoSQL)
// - InMemoryOrderRepository (testing)
// - CachedOrderRepository (decorator adding caching)

Pattern 2: Service Interface

Defines business operations at a higher abstraction level than repositories, often coordinating multiple resources.

service_interface.ts
1
2
3
4
5
6
7
8
9
10
11
interface PaymentService {
    processPayment(order: Order, paymentMethod: PaymentMethod): Promise<PaymentResult>;
    initiateRefund(orderId: OrderId, amount: Money): Promise<RefundResult>;
    getPaymentStatus(paymentId: PaymentId): Promise<PaymentStatus>;
}
 
// Hides complexity of:
// - Payment gateway selection
// - Fraud detection
// - Currency conversion
// - Retry logic

Pattern 3: Strategy Interface

Defines a family of interchangeable algorithms or policies.

strategy_interface.ts
1
2
3
4
5
6
7
8
interface PricingStrategy {
    calculatePrice(product: Product, customer: Customer): Money;
}
 
class StandardPricing implements PricingStrategy { /* ... */ }
class VIPDiscountPricing implements PricingStrategy { /* ... */ }
class PromotionalPricing implements PricingStrategy { /* ... */ }
class RegionalPricing implements PricingStrategy { /* ... */ }

Pattern 4: Observer/Listener Interface

Defines the callback contract for event handling.

observer_interface.ts
1
2
3
4
5
6
7
8
9
10
11
interface OrderEventListener {
    onOrderCreated(event: OrderCreatedEvent): void;
    onOrderShipped(event: OrderShippedEvent): void;
    onOrderDelivered(event: OrderDeliveredEvent): void;
    onOrderCancelled(event: OrderCancelledEvent): void;
}
 
// Different listeners for different concerns
class InventoryAdjuster implements OrderEventListener { /* ... */ }
class CustomerNotifier implements OrderEventListener { /* ... */ }
class AnalyticsTracker implements OrderEventListener { /* ... */ }

Pattern 5: Factory Interface

Abstracts object creation, allowing different creation strategies.

factory_interface.ts
1
2
3
4
5
6
7
8
9
interface NotificationFactory {
    createNotification(type: NotificationType, content: NotificationContent): Notification;
}
 
// Different factories for different contexts
class EmailNotificationFactory implements NotificationFactory { /* ... */ }
class PushNotificationFactory implements NotificationFactory { /* ... */ }
class SMSNotificationFactory implements NotificationFactory { /* ... */ }
class AggregateNotificationFactory implements NotificationFactory { /* combines multiple */ }

Patterns Are Guides, Not Rules

These patterns are starting points, not prescriptions. Adapt them to your specific needs. The goal is to create useful abstractions, not to rigidly follow pattern templates. Sometimes an interface doesn't fit any named pattern but is exactly right for your situation.

Interfaces in Practice: A Case Study

Let's walk through a realistic scenario to see how interfaces enable dependency inversion in a complete system.

Scenario: Order Processing System

We're building an e-commerce order processing system. Orders must be:

Validated against inventory
Charged via payment processor
Recorded in the database
Customer notified
Analytics tracked

The Interface-Driven Architecture:

order_processing_system.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
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
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
// ===============================================
// INTERFACES - Owned by the domain/core layer
// ===============================================
 
interface InventoryChecker {
    checkAvailability(items: OrderItem[]): Promise<AvailabilityResult>;
    reserve(items: OrderItem[], orderId: OrderId): Promise<ReservationResult>;
    release(orderId: OrderId): Promise<void>;
}
 
interface PaymentProcessor {
    charge(order: Order, paymentMethod: PaymentMethod): Promise<ChargeResult>;
    refund(chargeId: ChargeId, amount: Money): Promise<RefundResult>;
}
 
interface OrderRepository {
    save(order: Order): Promise<Order>;
    findById(id: OrderId): Promise<Order | null>;
    updateStatus(id: OrderId, status: OrderStatus): Promise<void>;
}
 
interface CustomerNotifier {
    notifyOrderConfirmation(order: Order): Promise<void>;
    notifyOrderShipped(order: Order, tracking: TrackingInfo): Promise<void>;
    notifyOrderCancelled(order: Order, reason: string): Promise<void>;
}
 
interface AnalyticsTracker {
    trackOrderCreated(order: Order): void;
    trackOrderFulfilled(order: Order): void;
    trackRevenueRecorded(amount: Money): void;
}
 
// ===============================================
// DOMAIN SERVICE - Depends only on interfaces
// ===============================================
 
class OrderProcessor {
    constructor(
        private inventoryChecker: InventoryChecker,
        private paymentProcessor: PaymentProcessor,
        private orderRepository: OrderRepository,
        private customerNotifier: CustomerNotifier,
        private analyticsTracker: AnalyticsTracker,
    ) {}
    
    async processOrder(orderRequest: OrderRequest): Promise<OrderResult> {
        // 1. Check inventory
        const availability = await this.inventoryChecker.checkAvailability(orderRequest.items);
        if (!availability.allAvailable) {
            return OrderResult.failed('Items not available', availability.unavailable);
        }
        
        // 2. Reserve inventory
        const reservation = await this.inventoryChecker.reserve(
            orderRequest.items, 
            orderRequest.orderId
        );
        
        try {
            // 3. Process payment
            const order = Order.create(orderRequest);
            const chargeResult = await this.paymentProcessor.charge(
                order, 
                orderRequest.paymentMethod
            );
            
            if (!chargeResult.success) {
                await this.inventoryChecker.release(orderRequest.orderId);
                return OrderResult.failed('Payment failed', chargeResult.error);
            }
            
            // 4. Persist order
            order.markAsPaid(chargeResult.chargeId);
            await this.orderRepository.save(order);
            
            // 5. Notify customer (fire and forget)
            this.customerNotifier.notifyOrderConfirmation(order).catch(console.error);
            
            // 6. Track analytics (fire and forget)
            this.analyticsTracker.trackOrderCreated(order);
            this.analyticsTracker.trackRevenueRecorded(order.total);
            
            return OrderResult.success(order);
            
        } catch (error) {
            // Compensating transaction: release inventory
            await this.inventoryChecker.release(orderRequest.orderId);
            throw error;
        }
    }
}

The Power of This Design:

The OrderProcessor class is completely isolated from:

Whether inventory is tracked in a local database, ERP system, or microservice
Whether payments go through Stripe, Braintree, or a custom processor
Whether orders are stored in PostgreSQL, MongoDB, or event sourced
Whether notifications use email, SMS, push, or all three
Whether analytics goes to Mixpanel, Amplitude, or a data warehouse

This means:

1. Testing is Trivial:

order_processor_test.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
35
describe('OrderProcessor', () => {
    let processor: OrderProcessor;
    let mockInventory: jest.Mocked<InventoryChecker>;
    let mockPayment: jest.Mocked<PaymentProcessor>;
    let mockRepository: jest.Mocked<OrderRepository>;
    let mockNotifier: jest.Mocked<CustomerNotifier>;
    let mockAnalytics: jest.Mocked<AnalyticsTracker>;
    
    beforeEach(() => {
        mockInventory = createMockInventory();
        mockPayment = createMockPayment();
        mockRepository = createMockRepository();
        mockNotifier = createMockNotifier();
        mockAnalytics = createMockAnalytics();
        
        processor = new OrderProcessor(
            mockInventory,
            mockPayment,
            mockRepository,
            mockNotifier,
            mockAnalytics,
        );
    });
    
    it('should release inventory when payment fails', async () => {
        mockInventory.checkAvailability.mockResolvedValue({ allAvailable: true });
        mockInventory.reserve.mockResolvedValue({ success: true });
        mockPayment.charge.mockResolvedValue({ success: false, error: 'Declined' });
        
        const result = await processor.processOrder(createTestOrder());
        
        expect(result.success).toBe(false);
        expect(mockInventory.release).toHaveBeenCalledWith(expect.any(String));
    });
});

2. Replacing Components is Safe:

When migrating from Stripe to a new payment processor, you:

Create NewPaymentProcessor implements PaymentProcessor
Test the new implementation independently
Swap the dependency injection configuration
OrderProcessor never changes

3. Different Configurations for Different Contexts:

Development: Mock implementations
Staging: Real but sandboxed implementations
Production: Full production implementations
Load Testing: Implementations with chaos injection

All without any changes to the core business logic.

The Interface Dividend

The upfront investment in defining clean interfaces pays dividends throughout the system's lifetime. Every new requirement, bug fix, or infrastructure change is easier because the core logic is insulated from the changing periphery. This is the essence of sustainable software architecture.

Summary: Interfaces as the Foundation of Abstraction

We've explored interfaces from their philosophical foundations to practical application. Let's consolidate the key insights:

Key Takeaways

•Interfaces define contracts, not implementations — They specify what operations are available without dictating how those operations are performed.
•Interfaces enable dependency inversion — By placing an interface between components, both sides depend on the abstraction rather than each other.
•Good interfaces are consumer-driven — Design from the perspective of what clients need, not what implementations can do.
•Interface Segregation matters — Keep interfaces small and focused; fat interfaces create unnecessary coupling.
•Interfaces should be stable — Treat published interfaces as contracts; prefer adding new interfaces over changing existing ones.
•Interfaces enable testing — Mock implementations make isolated unit testing practical.
•Interfaces enable flexibility — Swap implementations without affecting consumers; evolve systems incrementally.

The Architectural Perspective:

Interfaces are not just a language feature—they are the primary mechanism for creating architectural boundaries. In a well-designed system, interfaces define the seams along which components can be developed, tested, deployed, and replaced independently. They are the contracts that make large-scale software possible.

What's Next:

Now that we understand interfaces as abstraction mechanisms, we'll explore a crucial question: Who owns these interfaces? The answer has profound implications for system architecture, and getting it wrong is one of the most common DIP violations. The next page examines the Ownership of Abstractions and why it matters.

Page Complete

You now understand interfaces as the primary abstraction mechanism for achieving dependency inversion. You've seen how interfaces create stable boundaries, enable testing, and provide flexibility. Next, we'll explore who should own these interfaces—a decision that determines whether DIP actually works in practice.