From Design to Code - Learning Module

Loading content...

0/246

Interface First, Implementation Second

Contracts Before Construction

Imagine constructing a building without blueprints—laying bricks and hoping walls align with windows, that floors meet doorways, that plumbing reaches bathrooms. The result would be chaos.

Yet many developers approach code exactly this way: diving into implementation details before clearly defining what components must do. They write concrete classes first, then extract interfaces after the fact—if at all.

Interface-first development inverts this pattern. You define the contract—what a component promises to do—before writing the code that fulfills that promise. This approach is fundamental to professional software engineering and essential in LLD interviews.

This page explores why interface-first design produces better code, how to practice it effectively, and how to apply it under the time pressure of technical interviews.

What You Will Learn

By the end of this page, you will understand the concrete benefits of interface-first design, how to identify what should be an interface versus a class, techniques for designing effective interfaces, the relationship between interfaces and testability, and how to apply interface-first principles under interview time constraints.

The Philosophy of Interface-First Design

The interface-first philosophy is rooted in a simple observation: consumers of code care about what it does, not how it does it.

When you call a payment processor, you care that it charges a card and returns a result. You don't care whether it uses HTTP or gRPC, whether it retries three times or five, whether it logs to CloudWatch or Datadog. These are implementation details invisible to the caller.

The Interface is the API:

An interface defines the public contract between components:

What operations are available
What inputs each operation requires
What outputs each operation produces
What guarantees the operation provides

Everything else—algorithms, data structures, external dependencies, error handling strategies—is implementation that can vary without affecting callers.

Implementation-First Problems

•Tight coupling — Callers depend on concrete types, breaking when implementations change
•Hard to test — Can't substitute mocks without modifying code
•Design rigidity — Adding new implementations requires changing callers
•Leaked details — Internal methods exposed because they're 'useful'
•Premature optimization — Implementation choices made before requirements are clear

Interface-First Benefits

•Loose coupling — Callers depend on stable contracts, not changeable implementations
•Easily testable — Substitute test doubles without code changes
•Open for extension — New implementations added without modifying callers
•Clean boundaries — Only intended operations exposed
•Deferred decisions — Implementation details can be optimized later

The Principal Engineer's Mindset

Senior engineers think in interfaces first because they've experienced the pain of not doing so. They've seen how a 'simple' change to a concrete class rippled through 50 files. They've struggled to test code that created its own dependencies. Interface-first isn't academic—it's hard-won wisdom.

Identifying What Should Be an Interface

Not everything needs to be an interface. Over-abstraction creates unnecessary complexity. The art is recognizing where abstraction adds value.

Strong Candidates for Interfaces:

When to Use Interfaces
Scenario	Why Interface Helps	Example
Multiple implementations expected	Enables polymorphic substitution	PaymentProcessor → Stripe, PayPal, Square
External system integration	Isolates from vendor-specific APIs	EmailService → SendGrid, AWS SES, SMTP
Cross-cutting concerns	Consistent handling across contexts	Logger, MetricsCollector, Tracer
Strategy pattern candidates	Algorithm can vary at runtime	PricingStrategy, RoutingStrategy
Repository/data access	Database technology can change	UserRepository → SQL, MongoDB, InMemory
Testability requirements	Need to mock in tests	TimeProvider, RandomGenerator

Poor Candidates for Interfaces:

Scenario	Why Interface Adds Noise	Better Approach
Value objects	Single, obvious implementation	Concrete class (Money, Address, Email)
Entity classes	Domain model is what it is	Concrete class (User, Order, Product)
Utility classes	Stateless pure functions	Static methods or concrete class
One-off classes	No variation expected	Concrete class, extract interface later if needed

The Litmus Test:

Ask these questions to decide:

"Will there ever be a second implementation?" — If yes, interface.
"Will I need to mock this in tests?" — If yes, interface.
"Is this an external dependency?" — If yes, interface.
"Does this represent a strategy or policy that might change?" — If yes, interface.

If all answers are "no" or "probably not," a concrete class is fine.

Interface vs Concrete Decision
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
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
// ================================================
// SHOULD BE INTERFACES: Multiple implementations, external deps
// ================================================
 
// ✅ PaymentProcessor - Multiple implementations expected
interface PaymentProcessor {
    processPayment(amount: Money, source: PaymentSource): Promise<PaymentResult>;
    refund(transactionId: string): Promise<RefundResult>;
}
 
class StripeProcessor implements PaymentProcessor { /* ... */ }
class PayPalProcessor implements PaymentProcessor { /* ... */ }
class SquareProcessor implements PaymentProcessor { /* ... */ }
 
// ✅ NotificationService - External system
interface NotificationService {
    send(recipient: string, message: string): Promise<void>;
}
 
class EmailNotificationService implements NotificationService { /* ... */ }
class SMSNotificationService implements NotificationService { /* ... */ }
class PushNotificationService implements NotificationService { /* ... */ }
 
// ✅ UserRepository - Data access abstraction
interface UserRepository {
    findById(id: string): Promise<User | null>;
    save(user: User): Promise<void>;
    findByEmail(email: string): Promise<User | null>;
}
 
class PostgresUserRepository implements UserRepository { /* ... */ }
class MongoUserRepository implements UserRepository { /* ... */ }
class InMemoryUserRepository implements UserRepository { /* ... */ } // For tests!
 
// ✅ TimeProvider - Testability requirement
interface TimeProvider {
    now(): Date;
    today(): Date;
}
 
class SystemTimeProvider implements TimeProvider {
    now(): Date { return new Date(); }
    today(): Date { 
        const now = new Date();
        return new Date(now.getFullYear(), now.getMonth(), now.getDate());
    }
}
 
class FixedTimeProvider implements TimeProvider {
    constructor(private fixedTime: Date) {}
    now(): Date { return this.fixedTime; }
    today(): Date { 
        return new Date(
            this.fixedTime.getFullYear(), 
            this.fixedTime.getMonth(), 
            this.fixedTime.getDate()
        );
    }
}
 
// ================================================
// SHOULD BE CONCRETE CLASSES: Value objects, entities
// ================================================
 
// ✅ Money - Value object, single implementation
class Money {
    constructor(
        private readonly amount: number,
        private readonly currency: string
    ) {
        if (amount < 0) throw new Error("Amount cannot be negative");
    }
    
    add(other: Money): Money {
        if (this.currency !== other.currency) {
            throw new Error("Cannot add different currencies");
        }
        return new Money(this.amount + other.amount, this.currency);
    }
    
    getAmount(): number { return this.amount; }
    getCurrency(): string { return this.currency; }
}
 
// ✅ User - Entity, represents domain concept
class User {
    constructor(
        private readonly id: string,
        private name: string,
        private email: string
    ) {}
    
    getId(): string { return this.id; }
    getName(): string { return this.name; }
    getEmail(): string { return this.email; }
    
    updateEmail(newEmail: string): void {
        // Validation logic
        this.email = newEmail;
    }
}
 
// ✅ EmailValidator - Utility, single implementation
class EmailValidator {
    private static readonly EMAIL_REGEX = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
    
    static isValid(email: string): boolean {
        return this.EMAIL_REGEX.test(email);
    }
}

YAGNI vs. Future-Proofing

YAGNI (You Aren't Gonna Need It) says don't add abstraction until needed. But for the scenarios listed above—external systems, multiple implementations, testability—the need is predictable. These aren't speculative abstractions; they're proven patterns that almost always pay off.

Designing Effective Interfaces

A well-designed interface is a pleasure to use. A poorly designed interface creates friction at every interaction. The difference often comes down to following established principles.

Interface Design Principles:

1. Interface Segregation (ISP)

Clients should not be forced to depend on methods they don't use. Split large interfaces into cohesive smaller ones.

Interface Segregation
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
// ❌ BAD: Fat interface forces unnecessary dependencies
interface UserService {
    createUser(data: CreateUserData): Promise<User>;
    updateUser(id: string, data: UpdateUserData): Promise<User>;
    deleteUser(id: string): Promise<void>;
    getUserById(id: string): Promise<User | null>;
    searchUsers(query: string): Promise<User[]>;
    exportUsers(format: 'csv' | 'json'): Promise<Buffer>;
    importUsers(data: Buffer): Promise<void>;
    sendPasswordReset(userId: string): Promise<void>;
    verifyEmail(userId: string, token: string): Promise<void>;
}
 
// A component that only reads users must depend on this entire interface!
 
// ✅ GOOD: Segregated interfaces
interface UserReader {
    getUserById(id: string): Promise<User | null>;
    searchUsers(query: string): Promise<User[]>;
}
 
interface UserWriter {
    createUser(data: CreateUserData): Promise<User>;
    updateUser(id: string, data: UpdateUserData): Promise<User>;
    deleteUser(id: string): Promise<void>;
}
 
interface UserImportExport {
    exportUsers(format: 'csv' | 'json'): Promise<Buffer>;
    importUsers(data: Buffer): Promise<void>;
}
 
interface UserAuthentication {
    sendPasswordReset(userId: string): Promise<void>;
    verifyEmail(userId: string, token: string): Promise<void>;
}
 
// Components depend only on what they need
class UserProfileDisplay {
    constructor(private userReader: UserReader) {} // Only read access
}
 
class UserAdmin {
    constructor(
        private userReader: UserReader,
        private userWriter: UserWriter
    ) {} // Read + Write
}

2. Abstraction at the Right Level

Interface methods should express what is needed, not how it's done:

Right Level of Abstraction
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
// ❌ BAD: Too low-level, exposes implementation details
interface MessageQueue {
    connectToRabbitMQ(host: string, port: number): Promise<void>;
    createExchange(name: string, type: 'direct' | 'fanout'): Promise<void>;
    bindQueueToExchange(queue: string, exchange: string, routingKey: string): Promise<void>;
    publishToExchange(exchange: string, routingKey: string, message: Buffer): Promise<void>;
    consumeFromQueue(queue: string, callback: (msg: Buffer) => void): Promise<void>;
}
 
// This interface is specific to RabbitMQ!
// Can't substitute Kafka, SQS, or in-memory queue without changing API.
 
// ✅ GOOD: Right abstraction level
interface MessagePublisher {
    publish(topic: string, message: object): Promise<void>;
}
 
interface MessageSubscriber {
    subscribe(topic: string, handler: (message: object) => Promise<void>): void;
    unsubscribe(topic: string): void;
}
 
// Implementation details hidden:
class RabbitMQPublisher implements MessagePublisher {
    async publish(topic: string, message: object): Promise<void> {
        // RabbitMQ-specific: connect, create exchange, publish
    }
}
 
class KafkaPublisher implements MessagePublisher {
    async publish(topic: string, message: object): Promise<void> {
        // Kafka-specific: produce to topic
    }
}
 
class InMemoryPublisher implements MessagePublisher {
    async publish(topic: string, message: object): Promise<void> {
        // For testing: store in memory
    }
}

3. Cohesive Method Signatures

Methods should have clear, focused purposes:

Cohesive Method Design
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
// ❌ BAD: Boolean flags indicate multiple responsibilities
interface OrderProcessor {
    processOrder(
        order: Order, 
        sendEmail: boolean, 
        updateInventory: boolean,
        generateInvoice: boolean
    ): Promise<ProcessResult>;
}
 
// Caller must know about all these side effects
// Hard to understand what happens with each flag combination
 
// ✅ GOOD: Single-responsibility methods
interface OrderProcessor {
    processOrder(order: Order): Promise<ProcessResult>;
}
 
interface NotificationService {
    sendOrderConfirmation(order: Order): Promise<void>;
}
 
interface InventoryService {
    reserveItems(items: OrderItem[]): Promise<void>;
}
 
interface InvoiceService {
    generateInvoice(order: Order): Promise<Invoice>;
}
 
// Orchestrator combines them explicitly:
class OrderWorkflow {
    constructor(
        private orderProcessor: OrderProcessor,
        private notifications: NotificationService,
        private inventory: InventoryService,
        private invoices: InvoiceService
    ) {}
    
    async completeOrder(order: Order): Promise<void> {
        const result = await this.orderProcessor.processOrder(order);
        
        // Each step is explicit and optional
        await this.inventory.reserveItems(order.items);
        await this.notifications.sendOrderConfirmation(order);
        const invoice = await this.invoices.generateInvoice(order);
        // ...
    }
}

The Consumer Test

When designing an interface, imagine writing code that uses it BEFORE implementing it. If the API feels awkward or requires the caller to understand implementation details, redesign. An interface should make the consumer's code clean and obvious.

The Interface-First Development Workflow

Interface-first isn't just a principle—it's a workflow. Here's the systematic process for applying it:

The Six-Step Workflow:

Interface-First Workflow

•Identify responsibilities — What operations does this component need to perform?
•Define the interface — Write method signatures that express those operations
•Write consumer code — Use the interface before implementing it (validates the API)
•Review and refine — Adjust the interface based on how it feels to use
•Implement — Write the concrete class that fulfills the contract
•Test — Verify implementation satisfies the interface contract

Interface-First Workflow Example
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
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
// ================================================
// STEP 1: Identify Responsibilities
// ================================================
 
// Scenario: We need a component to manage parking tickets
// Responsibilities:
// - Issue a new ticket when a vehicle parks
// - Calculate fees when vehicle leaves
// - Process payment for the ticket
// - Track active tickets
 
// ================================================
// STEP 2: Define the Interface
// ================================================
 
interface ParkingTicketService {
    issueTicket(vehicle: Vehicle, spot: ParkingSpot): Ticket;
    calculateFee(ticket: Ticket): Money;
    completeTicket(ticket: Ticket, payment: Payment): TicketReceipt;
    getActiveTickets(): Ticket[];
    findTicketByVehicle(licensePlate: string): Ticket | null;
}
 
// Also define related interfaces for dependencies
interface PricingStrategy {
    calculatePrice(duration: Duration, vehicleType: VehicleType): Money;
}
 
// ================================================
// STEP 3: Write Consumer Code (before implementing!)
// ================================================
 
class ParkingLotController {
    constructor(
        private ticketService: ParkingTicketService,
        private spotFinder: SpotFinder,
        private paymentProcessor: PaymentProcessor
    ) {}
    
    async parkVehicle(vehicle: Vehicle): Promise<Ticket> {
        // Using interface before it exists - validates API design
        const spot = await this.spotFinder.findAvailableSpot(vehicle.getType());
        if (!spot) {
            throw new Error("No available spots");
        }
        
        return this.ticketService.issueTicket(vehicle, spot);
        // Does this feel natural? Is the return type right?
    }
    
    async exitVehicle(licensePlate: string): Promise<TicketReceipt> {
        const ticket = this.ticketService.findTicketByVehicle(licensePlate);
        if (!ticket) {
            throw new Error("No active ticket for vehicle");
        }
        
        const fee = this.ticketService.calculateFee(ticket);
        // Hmm, we need to collect payment first...
        
        const payment = await this.paymentProcessor.collectPayment(fee);
        return this.ticketService.completeTicket(ticket, payment);
        // This flow feels right
    }
}
 
// ================================================
// STEP 4: Review and Refine
// ================================================
 
// After using the interface, we realize:
// 1. We need to mark spots as occupied/available
// 2. Ticket should know its spot for spot release
 
// Refined interface:
interface ParkingTicketServiceV2 {
    issueTicket(vehicle: Vehicle, spot: ParkingSpot): Ticket;
    calculateFee(ticketId: string): Money; // Use ID instead of object
    completeTicket(ticketId: string, payment: Payment): TicketReceipt;
    getActiveTickets(): Ticket[];
    findActiveTicketByVehicle(licensePlate: string): Ticket | null;
    cancelTicket(ticketId: string): void; // Added for edge cases
}
 
// ================================================
// STEP 5: Implement
// ================================================
 
class DefaultParkingTicketService implements ParkingTicketServiceV2 {
    private tickets: Map<string, Ticket> = new Map();
    private activeByVehicle: Map<string, Ticket> = new Map();
    
    constructor(private pricingStrategy: PricingStrategy) {}
    
    issueTicket(vehicle: Vehicle, spot: ParkingSpot): Ticket {
        const ticket = new Ticket(
            this.generateId(),
            vehicle,
            spot,
            new Date()
        );
        
        this.tickets.set(ticket.getId(), ticket);
        this.activeByVehicle.set(vehicle.getLicensePlate(), ticket);
        spot.occupy();
        
        return ticket;
    }
    
    calculateFee(ticketId: string): Money {
        const ticket = this.getTicketOrThrow(ticketId);
        const duration = this.calculateDuration(ticket.getEntryTime(), new Date());
        
        return this.pricingStrategy.calculatePrice(
            duration, 
            ticket.getVehicle().getType()
        );
    }
    
    completeTicket(ticketId: string, payment: Payment): TicketReceipt {
        const ticket = this.getTicketOrThrow(ticketId);
        const fee = this.calculateFee(ticketId);
        
        if (payment.getAmount().isLessThan(fee)) {
            throw new Error("Insufficient payment");
        }
        
        ticket.complete();
        ticket.getSpot().vacate();
        this.activeByVehicle.delete(ticket.getVehicle().getLicensePlate());
        
        return new TicketReceipt(ticket, payment, fee);
    }
    
    getActiveTickets(): Ticket[] {
        return Array.from(this.activeByVehicle.values());
    }
    
    findActiveTicketByVehicle(licensePlate: string): Ticket | null {
        return this.activeByVehicle.get(licensePlate) || null;
    }
    
    cancelTicket(ticketId: string): void {
        const ticket = this.getTicketOrThrow(ticketId);
        ticket.cancel();
        ticket.getSpot().vacate();
        this.activeByVehicle.delete(ticket.getVehicle().getLicensePlate());
    }
    
    private getTicketOrThrow(ticketId: string): Ticket {
        const ticket = this.tickets.get(ticketId);
        if (!ticket) throw new Error(`Ticket not found: ${ticketId}`);
        return ticket;
    }
    
    private generateId(): string {
        return `TKT-${Date.now()}-${Math.random().toString(36).substr(2, 9)}`;
    }
    
    private calculateDuration(start: Date, end: Date): Duration {
        const ms = end.getTime() - start.getTime();
        return Duration.ofMinutes(Math.ceil(ms / 60000));
    }
}
 
// ================================================
// STEP 6: Test
// ================================================
 
describe('DefaultParkingTicketService', () => {
    let service: ParkingTicketServiceV2;
    let mockPricing: PricingStrategy;
    
    beforeEach(() => {
        mockPricing = {
            calculatePrice: jest.fn().mockReturnValue(new Money(10, 'USD'))
        };
        service = new DefaultParkingTicketService(mockPricing);
    });
    
    it('should issue ticket and mark spot as occupied', () => {
        const vehicle = new Car('ABC-123');
        const spot = new CompactSpot('A1');
        
        const ticket = service.issueTicket(vehicle, spot);
        
        expect(ticket.getVehicle()).toBe(vehicle);
        expect(ticket.getSpot()).toBe(spot);
        expect(spot.isOccupied()).toBe(true);
    });
    
    it('should calculate fee using pricing strategy', () => {
        const vehicle = new Car('ABC-123');
        const spot = new CompactSpot('A1');
        const ticket = service.issueTicket(vehicle, spot);
        
        const fee = service.calculateFee(ticket.getId());
        
        expect(mockPricing.calculatePrice).toHaveBeenCalled();
        expect(fee.getAmount()).toBe(10);
    });
    
    // More tests...
});

Interfaces and Testability

One of the most powerful benefits of interface-first design is testability. When components depend on interfaces rather than concrete classes, substituting test doubles becomes trivial.

The Testing Advantage:

Without interfaces, testing requires:

Creating real external connections (databases, APIs)
Complex setup and teardown
Slow, flaky tests
Inability to simulate error conditions

With interfaces, testing becomes:

Fast (no external connections)
Isolated (each test controls its dependencies)
Deterministic (no external state affects results)
Comprehensive (error paths easily tested)

Interface-Enabled Testing
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
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
// ================================================
// Without Interfaces: Hard to Test
// ================================================
 
// ❌ Direct dependency on concrete class
class OrderService {
    private stripeClient = new StripeClient(process.env.STRIPE_KEY!);
    private emailClient = new SendGridClient(process.env.SENDGRID_KEY!);
    
    async placeOrder(order: Order): Promise<OrderResult> {
        // Charges real credit card!
        const payment = await this.stripeClient.charge(order.total);
        
        // Sends real email!
        await this.emailClient.send(order.customerEmail, 'Order Confirmation', '...');
        
        return { success: true, paymentId: payment.id };
    }
}
 
// How do you test this?
// - Need real Stripe API key
// - Will charge real money
// - Will send real emails
// - Tests are slow and flaky
 
// ================================================
// With Interfaces: Easily Testable
// ================================================
 
// ✅ Depend on interfaces
interface PaymentGateway {
    charge(amount: Money): Promise<PaymentResult>;
}
 
interface EmailSender {
    send(to: string, subject: string, body: string): Promise<void>;
}
 
class OrderServiceV2 {
    constructor(
        private paymentGateway: PaymentGateway,
        private emailSender: EmailSender
    ) {}
    
    async placeOrder(order: Order): Promise<OrderResult> {
        const payment = await this.paymentGateway.charge(order.total);
        await this.emailSender.send(order.customerEmail, 'Order Confirmation', '...');
        return { success: true, paymentId: payment.id };
    }
}
 
// ================================================
// Test with Mocks/Stubs
// ================================================
 
describe('OrderServiceV2', () => {
    // Create test doubles
    const mockPaymentGateway: PaymentGateway = {
        charge: jest.fn().mockResolvedValue({ 
            success: true, 
            id: 'test_payment_123' 
        })
    };
    
    const mockEmailSender: EmailSender = {
        send: jest.fn().mockResolvedValue(undefined)
    };
    
    let service: OrderServiceV2;
    
    beforeEach(() => {
        jest.clearAllMocks();
        service = new OrderServiceV2(mockPaymentGateway, mockEmailSender);
    });
    
    it('should charge payment and send confirmation email', async () => {
        const order = new Order('cust_1', [new OrderItem('SKU-1', 2)]);
        
        const result = await service.placeOrder(order);
        
        expect(result.success).toBe(true);
        expect(mockPaymentGateway.charge).toHaveBeenCalledWith(order.total);
        expect(mockEmailSender.send).toHaveBeenCalledWith(
            order.customerEmail,
            'Order Confirmation',
            expect.any(String)
        );
    });
    
    it('should handle payment failure', async () => {
        // Easy to simulate failure
        (mockPaymentGateway.charge as jest.Mock).mockRejectedValue(
            new Error('Card declined')
        );
        
        const order = new Order('cust_1', [new OrderItem('SKU-1', 2)]);
        
        await expect(service.placeOrder(order)).rejects.toThrow('Card declined');
        
        // Email should NOT be sent if payment fails
        expect(mockEmailSender.send).not.toHaveBeenCalled();
    });
    
    it('should continue if email fails (non-critical)', async () => {
        (mockEmailSender.send as jest.Mock).mockRejectedValue(
            new Error('Email service down')
        );
        
        const order = new Order('cust_1', [new OrderItem('SKU-1', 2)]);
        
        // Order should still succeed
        const result = await service.placeOrder(order);
        expect(result.success).toBe(true);
    });
});
 
// ================================================
// Special Test Doubles
// ================================================
 
// In-memory implementation for integration tests
class InMemoryPaymentGateway implements PaymentGateway {
    private payments: Payment[] = [];
    
    async charge(amount: Money): Promise<PaymentResult> {
        const payment = { id: `test_${Date.now()}`, amount, status: 'succeeded' };
        this.payments.push(payment);
        return { success: true, id: payment.id };
    }
    
    // Test helper methods
    getPayments(): Payment[] { return this.payments; }
    clear(): void { this.payments = []; }
}
 
// Time-controllable implementation
class TestableTimeProvider implements TimeProvider {
    private currentTime: Date;
    
    constructor(initialTime: Date = new Date()) {
        this.currentTime = initialTime;
    }
    
    now(): Date { return new Date(this.currentTime); }
    
    // Test helpers
    advanceMinutes(minutes: number): void {
        this.currentTime = new Date(this.currentTime.getTime() + minutes * 60000);
    }
    
    advanceHours(hours: number): void {
        this.advanceMinutes(hours * 60);
    }
}

The Dependency Injection Connection

Interface-first design enables dependency injection, which enables testability. These concepts form a virtuous triangle: interfaces define contracts, DI wires them together, and tests substitute mock implementations. Master this triangle and your code becomes dramatically easier to maintain and evolve.

Applying Interface-First in Interviews

In LLD interviews, interface-first thinking provides significant advantages:

Demonstrates architecture skills — Shows you think beyond immediate implementation
Enables skip-ahead — Define interfaces, then implement only critical ones
Communicates intent — Interviewer sees your design before code details
Reduces rework — Clean contracts prevent mid-implementation pivots

The Interview-Optimized Approach:

Interview Interface Strategy

•In the design phase — Identify key abstractions and sketch their interfaces
•When starting implementation — Write interfaces first (2-3 minutes)
•Verbalize to interviewer — 'I'll define the interfaces first so the contracts are clear'
•Implement core interfaces — Focus on the primary flow's interfaces
•Stub secondary interfaces — Mention but don't implement edge case handlers
•Show testing awareness — 'This interface would let us mock the payment gateway in tests'

Interview Interface Example
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
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
// ================================================
// Interview Scenario: Design a Ride-Sharing Service
// ================================================
 
// STEP 1: Define core interfaces (spend 2-3 minutes here)
// Say: "Let me first define the key interfaces so the design is clear"
 
interface RideMatchingService {
    findNearbyDrivers(location: Location, radiusKm: number): Promise<Driver[]>;
    selectBestDriver(drivers: Driver[], rideRequest: RideRequest): Driver;
}
 
interface PricingService {
    estimatePrice(origin: Location, destination: Location): Money;
    calculateFinalPrice(ride: CompletedRide): Money;
}
 
interface NotificationService {
    notifyDriver(driverId: string, notification: RideNotification): Promise<void>;
    notifyRider(riderId: string, notification: RideNotification): Promise<void>;
}
 
interface RideRepository {
    save(ride: Ride): Promise<void>;
    findById(rideId: string): Promise<Ride | null>;
    findActiveByRider(riderId: string): Promise<Ride | null>;
    findActiveByDriver(driverId: string): Promise<Ride | null>;
}
 
// STEP 2: Define the main orchestrator interface
interface RideService {
    requestRide(request: RideRequest): Promise<Ride>;
    acceptRide(rideId: string, driverId: string): Promise<Ride>;
    startRide(rideId: string): Promise<Ride>;
    completeRide(rideId: string): Promise<Ride>;
    cancelRide(rideId: string, reason: string): Promise<Ride>;
}
 
// Say: "These interfaces define the contracts. Now I'll implement the core flow."
 
// STEP 3: Implement only what's critical
class DefaultRideService implements RideService {
    constructor(
        private matching: RideMatchingService,
        private pricing: PricingService,
        private notifications: NotificationService,
        private rides: RideRepository
    ) {}
    
    async requestRide(request: RideRequest): Promise<Ride> {
        // Estimate price
        const estimatedPrice = this.pricing.estimatePrice(
            request.pickup, 
            request.destination
        );
        
        // Find nearby drivers
        const drivers = await this.matching.findNearbyDrivers(
            request.pickup, 
            5 // 5km radius
        );
        
        if (drivers.length === 0) {
            throw new Error("No drivers available");
        }
        
        // Select best driver
        const driver = this.matching.selectBestDriver(drivers, request);
        
        // Create ride
        const ride = new Ride(
            this.generateId(),
            request.riderId,
            driver.getId(),
            request.pickup,
            request.destination,
            estimatedPrice,
            RideStatus.REQUESTED
        );
        
        await this.rides.save(ride);
        
        // Notify driver
        await this.notifications.notifyDriver(driver.getId(), {
            type: 'RIDE_REQUEST',
            rideId: ride.getId(),
            pickup: request.pickup
        });
        
        return ride;
    }
    
    async acceptRide(rideId: string, driverId: string): Promise<Ride> {
        const ride = await this.getRideOrThrow(rideId);
        
        if (ride.getDriverId() !== driverId) {
            throw new Error("Unauthorized");
        }
        
        ride.accept();
        await this.rides.save(ride);
        
        await this.notifications.notifyRider(ride.getRiderId(), {
            type: 'RIDE_ACCEPTED',
            rideId: rideId,
            driverName: "..." // Would fetch from driver service
        });
        
        return ride;
    }
    
    // Say: "startRide and completeRide follow similar patterns.
    // I'll implement them the same way if time permits."
    
    async startRide(rideId: string): Promise<Ride> {
        const ride = await this.getRideOrThrow(rideId);
        ride.start();
        await this.rides.save(ride);
        return ride;
    }
    
    async completeRide(rideId: string): Promise<Ride> {
        const ride = await this.getRideOrThrow(rideId);
        
        // Calculate final price (might differ from estimate)
        const finalPrice = this.pricing.calculateFinalPrice({
            origin: ride.getPickup(),
            destination: ride.getDestination(),
            startTime: ride.getStartTime()!,
            endTime: new Date()
        });
        
        ride.complete(finalPrice);
        await this.rides.save(ride);
        
        // Notify both parties
        await Promise.all([
            this.notifications.notifyRider(ride.getRiderId(), {
                type: 'RIDE_COMPLETED',
                rideId,
                finalPrice
            }),
            this.notifications.notifyDriver(ride.getDriverId(), {
                type: 'RIDE_COMPLETED',
                rideId,
                earnings: finalPrice // Simplified
            })
        ]);
        
        return ride;
    }
    
    async cancelRide(rideId: string, reason: string): Promise<Ride> {
        // Say: "Cancel follows the same pattern with appropriate state transitions"
        const ride = await this.getRideOrThrow(rideId);
        ride.cancel(reason);
        await this.rides.save(ride);
        return ride;
    }
    
    private async getRideOrThrow(rideId: string): Promise<Ride> {
        const ride = await this.rides.findById(rideId);
        if (!ride) throw new Error(`Ride not found: ${rideId}`);
        return ride;
    }
    
    private generateId(): string {
        return `RIDE-${Date.now()}`;
    }
}
 
// Say: "The other services (RideMatchingService, PricingService, etc.)
// would be implemented following the same interface-first pattern.
// For RideMatchingService, I'd use a spatial index for efficient 
// nearby-driver queries..."

Time Allocation

In a 45-minute LLD interview, spend 2-3 minutes defining core interfaces before implementation. This investment pays off by clarifying your design, enabling focused implementation, and demonstrating architectural maturity to the interviewer.

Summary: Interface First, Implementation Second

We've explored the interface-first philosophy, its benefits, and practical application. Here are the key principles:

Key Takeaways

•Interfaces define contracts — What a component does, not how it does it
•Use interfaces strategically — For external systems, multiple implementations, and testability
•Design for consumers — Write code that uses the interface before implementing it
•Keep interfaces cohesive — Apply Interface Segregation Principle
•Interfaces enable testing — Substitute mocks/stubs without code changes
•In interviews — Define interfaces first to clarify design and demonstrate maturity

Page Complete

You now understand why interface-first development produces better code and how to apply it in both production and interview settings. The key insight is that interfaces aren't extra work—they're the design itself, made explicit. Next, we'll explore incremental implementation: building systems piece by piece with continuous validation.

What's next:

The final page in this module covers Incremental Implementation—the practice of building working systems piece by piece, validating at each step, and maintaining a shippable product throughout development.