System Design (LLD)The Power of Programming to Interfaces

The Power of Programming to Interfaces

LevelIntermediate

Duration60 mins

TopicThe Power of Programming to Interfaces

4 / 4

Interface-Based Design

Designing with Interfaces as First-Class Citizens

We've explored why to depend on abstractions, how interfaces enable flexibility, and how they reduce coupling. Now we bring everything together into a cohesive approach: interface-based design.

In interface-based design, interfaces aren't an afterthought or a testing convenience—they're the primary architectural element. You design interfaces first, before implementations. You think in terms of contracts and collaborations, not classes and methods. The structure of your system emerges from the way interfaces interact.

This approach transforms how you design software. Instead of asking "What classes do I need?", you ask "What contracts define how components collaborate?" The resulting systems are more flexible, more testable, and more aligned with the problem domain.

What You Will Learn

By the end of this page, you will understand how to apply interface-first design, structure systems around collaborating interfaces, and use interfaces to model domain concepts. You'll have a complete framework for designing systems where interfaces drive architecture.

Interface-First Design Process

Interface-first design inverts the typical development flow. Instead of writing classes and extracting interfaces later, you define interfaces first based on the capabilities your system needs.

The interface-first process:

Design Process Steps

•Identify required capabilities — What actions must the system perform? What services must components provide to each other?
•Define interfaces for each capability — Express each capability as an interface with its methods, parameters, and return types.
•Model collaborations between interfaces — How do interfaces work together? Which interfaces depend on which?
•Implement the interfaces — Create concrete classes that fulfill the contracts. This happens last, not first.
•Wire implementations together — Use dependency injection or factory patterns to connect implementations to consumers.

Example: Designing an e-commerce checkout system

Step 1: Identify capabilities

CapabilityIdentification.txt
1
2
3
4
5
6
7
8
9
10
Required capabilities for checkout:
- Calculate pricing (discounts, taxes, shipping)
- Validate inventory availability
- Process payment
- Create order record
- Reserve inventory
- Send confirmation notification
- Handle failures gracefully
 
Each capability becomes an interface.

Step 2: Define interfaces

CheckoutInterfaces.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
// Price calculation capability
public interface PricingService {
    PricingResult calculatePrice(Cart cart, Customer customer, ShippingOption shipping);
}
 
public record PricingResult(
    Money subtotal,
    Money discount,
    Money tax,
    Money shipping,
    Money total,
    List<AppliedPromotion> promotions
) {}
 
// Inventory capability
public interface InventoryService {
    AvailabilityResult checkAvailability(List<CartItem> items);
    ReservationResult reserve(List<CartItem> items, Duration holdTime);
    void release(ReservationId reservationId);
}
 
// Payment capability
public interface PaymentGateway {
    PaymentResult authorize(Money amount, PaymentMethod method);
    PaymentResult capture(PaymentId authorizationId);
    void cancel(PaymentId authorizationId);
}
 
// Order persistence capability
public interface OrderRepository {
    Order save(Order order);
    Optional<Order> findById(OrderId id);
    void updateStatus(OrderId id, OrderStatus status);
}
 
// Notification capability
public interface NotificationService {
    void sendOrderConfirmation(Order order, Customer customer);
    void sendOrderFailed(Customer customer, String reason);
}
 
// Each interface is:
// - Named by capability (what it does), not implementation (how)
// - Minimal (only necessary methods)
// - Complete (everything needed for that capability)
// - Documented (contracts are explicit)

Step 3: Model collaborations

Converting Mermaid diagram...

Interfaces Define the System Shape

Notice that we've defined the structure of the checkout system before writing any implementation code. We know what capabilities exist, what each provides, and how they collaborate. Implementation is filling in boxes of a predefined structure.

Designing Cohesive Interface Contracts

The quality of your interfaces determines the quality of your system. Well-designed interfaces are cohesive—all methods relate to a single capability—and complete—they provide everything needed for that capability.

Principles for cohesive interfaces:

Interface Design Principles
Principle	Description	Example
Single Capability	All methods serve one coherent purpose	`OrderRepository` only handles order persistence, not pricing
Complete Abstraction	Include all operations needed for the capability	`PaymentGateway` includes authorize, capture, AND cancel
Meaningful Names	Names describe what, not how	`NotificationService`, not `EmailAndSmsNotifier`
Appropriate Granularity	Neither too broad nor too narrow	One `InventoryService` vs split into `AvailabilityChecker`, `Reserver`, etc.
Implementation Agnostic	No implementation details leak through	No `getDbConnection()` on repository interfaces
Explicit Contracts	Document behavior, exceptions, thread safety	Javadoc specifying what exceptions are thrown when

Comparing interface designs:

PoorInterface.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// ❌ POOR DESIGN
public interface CustomerOperations {
    // Too many unrelated operations
    Customer findById(CustomerId id);
    void save(Customer customer);
    void delete(CustomerId id);
    
    // Why is pricing here?
    Money calculateDiscounts(Customer c);
    List<Promotion> getActivePromotions();
    
    // Why is notification here?
    void sendEmail(Customer c, String msg);
    void sendSms(Customer c, String msg);
    
    // Implementation detail leaked
    Connection getDbConnection();
    
    // Inconsistent abstraction level
    List<Order> getOrders(CustomerId id);
    String getFullName(CustomerId id);
}

GoodInterfaces.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// ✅ GOOD DESIGN
// Focused: only customer persistence
public interface CustomerRepository {
    Customer findById(CustomerId id);
    List<Customer> findBySegment(Segment s);
    void save(Customer customer);
    void delete(CustomerId id);
}
 
// Focused: only discount logic
public interface DiscountService {
    DiscountResult calculate(
        Customer customer, 
        List<CartItem> items
    );
}
 
// Focused: only outbound messaging
public interface NotificationService {
    void notify(Customer c, Notification n);
}
 
// Each interface:
// - Does one thing well
// - Is testable in isolation
// - Can evolve independently

Interface Segregation Principle

The principle of keeping interfaces focused is formalized as the Interface Segregation Principle (ISP)—the 'I' in SOLID. Clients should not be forced to depend on methods they don't use. Multiple focused interfaces are better than one large interface.

Role-Based Interfaces

A powerful interface design technique is to think in terms of roles rather than types. Instead of asking "What can this object do?", ask "What role does this object play in this context?"

Example: A single entity with multiple roles

Consider a User object. In different contexts, it plays different roles:

RoleBasedInterfaces.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
// Role: Something that can be authenticated
public interface AuthenticatedPrincipal {
    String getPrincipalId();
    Set<Permission> getPermissions();
    boolean hasPermission(Permission permission);
}
 
// Role: Something that receives notifications
public interface Notifiable {
    ContactPreferences getContactPreferences();
    String getEmail();
    Optional<String> getPhoneNumber();
}
 
// Role: Something that can purchase
public interface Purchaser {
    PaymentMethod getDefaultPaymentMethod();
    List<PaymentMethod> getSavedPaymentMethods();
    Address getDefaultShippingAddress();
}
 
// Role: Something whose activity can be audited
public interface Auditable {
    String getAuditIdentifier();
    Instant getLastActivityTime();
}
 
// The User class implements all roles it can play
public class User implements AuthenticatedPrincipal, 
                            Notifiable, 
                            Purchaser, 
                            Auditable {
    // Implementation for all roles
}
 
// Consumers depend only on the role they need
public class SecurityService {
    public void checkAccess(AuthenticatedPrincipal principal, Resource resource) {
        if (!principal.hasPermission(resource.requiredPermission())) {
            throw new AccessDeniedException();
        }
    }
    // SecurityService knows nothing about email, payment, etc.
}
 
public class NotificationService {
    public void send(Notifiable recipient, Message message) {
        ContactPreferences prefs = recipient.getContactPreferences();
        if (prefs.prefersEmail()) {
            emailSender.send(recipient.getEmail(), message);
        }
    }
    // NotificationService knows nothing about permissions, payments, etc.
}
 
public class CheckoutService {
    public void checkout(Purchaser purchaser, Cart cart) {
        PaymentMethod method = purchaser.getDefaultPaymentMethod();
        Address shipping = purchaser.getDefaultShippingAddress();
        // CheckoutService knows nothing about permissions, notifications, etc.
    }
}

Benefits of role-based interfaces:

•Minimal knowledge — Each consumer knows only what it needs. SecurityService doesn't know (or care) that principals have email addresses.
•Multiple implementations — Both User and ServiceAccount can implement AuthenticatedPrincipal. Both User and Organization can implement Notifiable.
•Easy testing — Create a simple test implementation of just the role being tested. No need to implement irrelevant methods.
•Flexible composition — New roles can be added without affecting existing interfaces. SubscriptionHolder doesn't impact Notifiable.
•Clear responsibilities — The interface name documents what role the object plays in this context.

Roles vs Types

Think of roles like costumes an actor wears. A single person (object) can play the doctor in one scene and the parent in another. The role defines what's relevant in that context. Methods should accept roles, not concrete types.

Interface Composition Patterns

Interfaces can be combined and composed in powerful ways. Understanding these patterns helps you design more flexible systems:

Pattern 1: Interface Inheritance

Extend interfaces to add capabilities:

InterfaceInheritance.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
// Base capability
public interface Repository<T, ID> {
    Optional<T> findById(ID id);
    T save(T entity);
    void delete(ID id);
}
 
// Extended capability
public interface QueryableRepository<T, ID> extends Repository<T, ID> {
    List<T> findAll();
    List<T> findBySpecification(Specification<T> spec);
    Page<T> findPage(PageRequest request);
}
 
// Further extended
public interface AuditableRepository<T, ID> extends Repository<T, ID> {
    List<T> findModifiedAfter(Instant timestamp);
    List<AuditLog> getHistory(ID id);
}
 
// Implementation can choose which level to support
public class UserRepository implements QueryableRepository<User, UserId> {
    // Must implement Repository + QueryableRepository methods
}
 
// Consumer can depend on what they need
public class ReportingService {
    private final QueryableRepository<Order, OrderId> orders;
    // Can use findAll(), findBySpecification(), etc.
}
 
public class SyncService {
    private final AuditableRepository<Product, ProductId> products;
    // Can use findModifiedAfter() for incremental sync
}

Pattern 2: Interface Combination

Implement multiple independent interfaces:

InterfaceCombination.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
// Independent capabilities
public interface Startup {
    void start();
    boolean isRunning();
}
 
public interface Shutdown {
    void shutdown();
    void shutdownNow();
    boolean awaitTermination(Duration timeout);
}
 
public interface HealthCheck {
    HealthStatus checkHealth();
}
 
// Combine for lifecycle-managed components
public interface ManagedService extends Startup, Shutdown, HealthCheck {
    // Inherits all methods from combined interfaces
}
 
// Consumer can work with any combination
public class ServiceManager {
    public void registerService(ManagedService service) {
        services.add(service);
    }
    
    public void startAll() {
        for (ManagedService service : services) {
            service.start();
        }
    }
    
    public HealthReport checkAllHealth() {
        return services.stream()
            .map(s -> s.checkHealth())
            .collect(toHealthReport());
    }
}
 
// Or accept just what's needed
public class HealthMonitor {
    public void register(HealthCheck checkable) {
        // Only needs health checking, not start/stop
        healthChecks.add(checkable);
    }
}

Pattern 3: Marker Interfaces

Signal capabilities without adding methods:

MarkerInterfaces.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// Marker: Indicates safe for concurrent access
public interface ThreadSafe {
    // No methods - merely a marker
}
 
// Marker: Indicates idempotent operations
public interface Idempotent {
    // No methods - signals retry safety
}
 
// Services can be tagged with markers
public class PaymentProcessor implements PaymentGateway, Idempotent {
    // Operations can be safely retried
}
 
public class ConcurrentCache implements Cache, ThreadSafe {
    // Safe for multi-threaded access
}
 
// Generic code can check for markers
public class RetryHandler {
    public <T> T executeWithRetry(Supplier<T> operation, Object service) {
        if (service instanceof Idempotent) {
            return executeWithRetries(operation, 3);
        } else {
            return operation.get(); // Single attempt only
        }
    }
}

Modern Alternative: Annotations

In modern Java and other languages, marker interfaces are often replaced by annotations (@ThreadSafe, @Idempotent). Annotations are metadata rather than types, so they don't affect interface hierarchies. Both approaches work; choose based on your ecosystem's conventions.

Domain-Driven Interface Design

The most powerful interface designs emerge from the domain—the problem space you're working in. Domain-driven interface design means interfaces reflect domain concepts, not technical implementation.

Contrast: Technical vs Domain Interfaces

TechnicalInterface.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// ❌ TECHNICAL FOCUS
// Named by technology
public interface 
    DatabaseOrderHandler {
    
    // Technical operations
    void insertRow(OrderDto dto);
    ResultSet queryByStatus(
        String status
    );
    void executeTransfer(
        Connection conn, 
        String sql
    );
    
    // Technical return types
    List<Map<String, Object>> 
        executeQuery(String sql);
}

DomainInterface.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// ✅ DOMAIN FOCUS
// Named by domain concept
public interface OrderRepository {
    
    // Domain operations
    Order save(Order order);
    Optional<Order> findById(
        OrderId id
    );
    List<Order> findPending();
    
    // Domain return types
    OrderSummary getSummary(
        OrderId id
    );
    
    // Domain exceptions
    // throws OrderNotFoundException
}

Using Ubiquitous Language:

Domain-driven design emphasizes ubiquitous language—a shared vocabulary used by developers and domain experts. Interfaces should use this language:

UbiquitousLanguage.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
// Domain: E-commerce fulfillment
// The business talks about "fulfilling orders" and "shipping"
 
// ❌ Generic programming terms
public interface ItemHandler {
    void process(ItemDto item);
    void move(ItemDto from, LocationDto to);
}
 
// ✅ Domain terms the business uses
public interface FulfillmentService {
    void fulfillOrder(Order order);              // Business action
    void shipToCustomer(Order order);            // Business action
    PackingSlip generatePackingSlip(Order order);// Business artifact
}
 
// ❌ Technical storage terms
public interface DataStore {
    void insert(Object entity);
    List<Object> query(Predicate pred);
}
 
// ✅ Domain-specific repository
public interface ShipmentRepository {
    Shipment findByTrackingNumber(TrackingNumber number);
    List<Shipment> findInTransit();
    List<Shipment> findDeliveredToday();  // Domain concept
}
 
// ❌ Generic messaging
public interface MessageSender {
    void send(String recipient, String content);
}
 
// ✅ Domain-specific communication
public interface CustomerCommunication {
    void sendShippingNotification(
        Customer customer, 
        Shipment shipment
    );
    void sendDeliveryConfirmation(
        Customer customer, 
        Shipment shipment,
        DeliveryProof proof
    );
}

Talk to Domain Experts

If your interface names confuse domain experts, you're speaking the wrong language. Good interfaces sound natural when discussed with business stakeholders: 'The FulfillmentService ships orders to customers.' If you say 'The ItemHandler processes ItemDtos,' something is wrong.

Interface-First Implementation

With interfaces defined, implementation follows. Here's a complete example showing how interface-first design leads to clean, testable code:

The checkout system implementation:

CheckoutImplementation.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
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
// The orchestrating service depends only on interfaces
public class CheckoutService {
    private final PricingService pricing;
    private final InventoryService inventory;
    private final PaymentGateway payments;
    private final OrderRepository orders;
    private final NotificationService notifications;
    
    // Constructor injection of all interfaces
    public CheckoutService(
            PricingService pricing,
            InventoryService inventory,
            PaymentGateway payments,
            OrderRepository orders,
            NotificationService notifications) {
        this.pricing = pricing;
        this.inventory = inventory;
        this.payments = payments;
        this.orders = orders;
        this.notifications = notifications;
    }
    
    public CheckoutResult checkout(Cart cart, Customer customer, 
                                   ShippingOption shipping, 
                                   PaymentMethod paymentMethod) {
        
        // 1. Calculate pricing
        PricingResult price = pricing.calculatePrice(cart, customer, shipping);
        
        // 2. Check & reserve inventory
        AvailabilityResult availability = inventory.checkAvailability(cart.getItems());
        if (!availability.isFullyAvailable()) {
            return CheckoutResult.outOfStock(availability.getUnavailableItems());
        }
        
        ReservationResult reservation = inventory.reserve(
            cart.getItems(), 
            Duration.ofMinutes(10)
        );
        
        try {
            // 3. Authorize payment
            PaymentResult payment = payments.authorize(price.total(), paymentMethod);
            if (!payment.isSuccessful()) {
                inventory.release(reservation.getId());
                notifications.sendOrderFailed(customer, payment.getErrorMessage());
                return CheckoutResult.paymentFailed(payment);
            }
            
            // 4. Create order
            Order order = Order.create(
                cart, 
                customer, 
                shipping, 
                price, 
                payment.getTransactionId()
            );
            Order savedOrder = orders.save(order);
            
            // 5. Capture payment
            payments.capture(payment.getTransactionId());
            
            // 6. Notify customer
            notifications.sendOrderConfirmation(savedOrder, customer);
            
            return CheckoutResult.success(savedOrder);
            
        } catch (Exception e) {
            // Compensating actions
            inventory.release(reservation.getId());
            throw new CheckoutException("Checkout failed", e);
        }
    }
}
 
// Test with fake implementations - no external dependencies
@Test
void checkout_successPath_createsOrderAndNotifies() {
    // Arrange: Simple fakes
    FakePricingService pricing = new FakePricingService(
        PricingResult.of(Money.of(99.99, USD))
    );
    FakeInventoryService inventory = new FakeInventoryService(
        AvailabilityResult.fullyAvailable()
    );
    FakePaymentGateway payments = new FakePaymentGateway(
        PaymentResult.success("TXN-123")
    );
    InMemoryOrderRepository orders = new InMemoryOrderRepository();
    RecordingNotificationService notifications = new RecordingNotificationService();
    
    CheckoutService service = new CheckoutService(
        pricing, inventory, payments, orders, notifications
    );
    
    // Act
    CheckoutResult result = service.checkout(cart, customer, shipping, card);
    
    // Assert
    assertThat(result.isSuccessful()).isTrue();
    assertThat(orders.findAll()).hasSize(1);
    assertThat(notifications.getConfirmationsSent()).hasSize(1);
}

Testing Becomes Trivial

Notice how testing requires no mocking frameworks, no database, no payment gateway credentials. Simple fake implementations fulfill the interface contracts. The test runs in milliseconds and verifies business logic in isolation.

Wiring It All Together

With interfaces designed and implemented, the final step is wiring—connecting implementations to consumers. This typically happens at application startup.

Common wiring approaches:

WiringApproaches.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
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
// ==========================================
// Approach 1: Manual Wiring (Pure Java)
// ==========================================
public class Application {
    public static void main(String[] args) {
        // Create implementations
        PricingService pricing = new StandardPricingService(
            new PromotionRepository(),
            new TaxCalculator()
        );
        InventoryService inventory = new WarehouseInventoryService(
            dataSource,
            redisClient
        );
        PaymentGateway payments = new StripePaymentGateway(
            stripeApiKey,
            webhookSecret
        );
        OrderRepository orders = new PostgresOrderRepository(dataSource);
        NotificationService notifications = new MultiChannelNotifier(
            new SendGridEmailer(apiKey),
            new TwilioSmsService(accountSid, authToken)
        );
        
        // Wire together
        CheckoutService checkout = new CheckoutService(
            pricing, inventory, payments, orders, notifications
        );
        
        // Start application with wired services
        new WebServer(checkout).start();
    }
}
 
// ==========================================
// Approach 2: Dependency Injection Framework (Spring)
// ==========================================
@Configuration
public class CheckoutConfiguration {
    
    @Bean
    public PricingService pricingService(
            PromotionRepository promos, 
            TaxCalculator tax) {
        return new StandardPricingService(promos, tax);
    }
    
    @Bean
    @Profile("production")
    public PaymentGateway productionPayments(
            @Value("${stripe.api.key}") String apiKey) {
        return new StripePaymentGateway(apiKey);
    }
    
    @Bean
    @Profile("development")
    public PaymentGateway developmentPayments() {
        return new FakePaymentGateway(); // No real charges
    }
    
    @Bean
    public CheckoutService checkoutService(
            PricingService pricing,
            InventoryService inventory,
            PaymentGateway payments,
            OrderRepository orders,
            NotificationService notifications) {
        return new CheckoutService(
            pricing, inventory, payments, orders, notifications
        );
    }
}
 
// ==========================================
// Approach 3: Module System (Guice-style)
// ==========================================
public class CheckoutModule extends AbstractModule {
    @Override
    protected void configure() {
        bind(PricingService.class).to(StandardPricingService.class);
        bind(PaymentGateway.class).to(StripePaymentGateway.class);
        bind(OrderRepository.class).to(PostgresOrderRepository.class);
        
        // Conditional binding
        if (isDevelopment()) {
            bind(NotificationService.class).to(LoggingNotifier.class);
        } else {
            bind(NotificationService.class).to(MultiChannelNotifier.class);
        }
    }
}

Wiring Best Practices

•Centralize wiring — Keep configuration in one place (the composition root). Don't scatter new across the codebase.
•Environment-specific implementations — Use profiles or conditions to swap implementations (production Stripe vs development fake).
•Fail fast — Verify all dependencies can be satisfied at startup, not when first used.
•Document the wiring — The composition root shows how the system is assembled. Make it readable.
•Consider performance — In rare cases, interface indirection matters. Wire critical paths thoughtfully.

Summary and Key Takeaways

We've completed our exploration of programming to interfaces with a comprehensive look at interface-based design. Let's consolidate everything we've learned across this module:

Module Key Takeaways

•Depend on abstractions, not implementations — This creates firewalls between components, enabling substitution and testing.
•Interfaces enable flexibility through substitution, decoration, and composition — Requirements change; interface-based designs accommodate change gracefully.
•Loose coupling is achieved through interface boundaries — Components know only contracts, not internals. Changes stay localized.
•Design interfaces first, then implement — This inverts the typical flow and produces cleaner architectures.
•Interfaces should be cohesive and minimal — Single capability, complete abstraction, no leaked implementation details.
•Think in roles, not types — Accept the narrowest interface that provides the needed capability.
•Use domain language in interface design — Interfaces should sound natural to domain experts.
•Composition patterns extend interface power — Inheritance, combination, and markers enable sophisticated designs.
•Wiring connects it all at startup — The composition root assembles implementations, keeping the rest of the code clean.

The principle in action:

"Program to an interface, not an implementation." — Gang of Four, Design Patterns (1994)

This principle, articulated over 30 years ago, remains one of the most powerful ideas in software design. It's the foundation of testable code, flexible architectures, and systems that can evolve gracefully.

As you continue your journey in system design, you'll see this principle appear again and again: in SOLID principles, in design patterns like Strategy and Observer, in architectural patterns like ports and adapters, and in modern practices like dependency injection. Master this concept, and you've mastered a cornerstone of professional software engineering.

Module Complete

Congratulations! You've completed the module on Programming to Interfaces. You now understand why to depend on abstractions, how interfaces enable flexibility and reduce coupling, and how to design systems where interfaces are first-class architectural elements. This knowledge will serve you throughout your career as you design flexible, testable, maintainable systems.

4 / 4

Loading learning content...

System Design (LLD)The Power of Programming to Interfaces

The Power of Programming to Interfaces

LevelIntermediate

Duration60 mins

TopicThe Power of Programming to Interfaces

4 / 4

Interface-Based Design

Designing with Interfaces as First-Class Citizens

We've explored why to depend on abstractions, how interfaces enable flexibility, and how they reduce coupling. Now we bring everything together into a cohesive approach: interface-based design.

What You Will Learn

Interface-First Design Process

Interface-first design inverts the typical development flow. Instead of writing classes and extracting interfaces later, you define interfaces first based on the capabilities your system needs.

The interface-first process:

Design Process Steps

•Identify required capabilities — What actions must the system perform? What services must components provide to each other?
•Define interfaces for each capability — Express each capability as an interface with its methods, parameters, and return types.
•Model collaborations between interfaces — How do interfaces work together? Which interfaces depend on which?
•Implement the interfaces — Create concrete classes that fulfill the contracts. This happens last, not first.
•Wire implementations together — Use dependency injection or factory patterns to connect implementations to consumers.

Example: Designing an e-commerce checkout system

Step 1: Identify capabilities

CapabilityIdentification.txt
1
2
3
4
5
6
7
8
9
10
Required capabilities for checkout:
- Calculate pricing (discounts, taxes, shipping)
- Validate inventory availability
- Process payment
- Create order record
- Reserve inventory
- Send confirmation notification
- Handle failures gracefully
 
Each capability becomes an interface.

Step 2: Define interfaces

CheckoutInterfaces.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
// Price calculation capability
public interface PricingService {
    PricingResult calculatePrice(Cart cart, Customer customer, ShippingOption shipping);
}
 
public record PricingResult(
    Money subtotal,
    Money discount,
    Money tax,
    Money shipping,
    Money total,
    List<AppliedPromotion> promotions
) {}
 
// Inventory capability
public interface InventoryService {
    AvailabilityResult checkAvailability(List<CartItem> items);
    ReservationResult reserve(List<CartItem> items, Duration holdTime);
    void release(ReservationId reservationId);
}
 
// Payment capability
public interface PaymentGateway {
    PaymentResult authorize(Money amount, PaymentMethod method);
    PaymentResult capture(PaymentId authorizationId);
    void cancel(PaymentId authorizationId);
}
 
// Order persistence capability
public interface OrderRepository {
    Order save(Order order);
    Optional<Order> findById(OrderId id);
    void updateStatus(OrderId id, OrderStatus status);
}
 
// Notification capability
public interface NotificationService {
    void sendOrderConfirmation(Order order, Customer customer);
    void sendOrderFailed(Customer customer, String reason);
}
 
// Each interface is:
// - Named by capability (what it does), not implementation (how)
// - Minimal (only necessary methods)
// - Complete (everything needed for that capability)
// - Documented (contracts are explicit)

Step 3: Model collaborations

Converting Mermaid diagram...

Interfaces Define the System Shape

Designing Cohesive Interface Contracts

Principles for cohesive interfaces:

Interface Design Principles
Principle	Description	Example
Single Capability	All methods serve one coherent purpose	`OrderRepository` only handles order persistence, not pricing
Complete Abstraction	Include all operations needed for the capability	`PaymentGateway` includes authorize, capture, AND cancel
Meaningful Names	Names describe what, not how	`NotificationService`, not `EmailAndSmsNotifier`
Appropriate Granularity	Neither too broad nor too narrow	One `InventoryService` vs split into `AvailabilityChecker`, `Reserver`, etc.
Implementation Agnostic	No implementation details leak through	No `getDbConnection()` on repository interfaces
Explicit Contracts	Document behavior, exceptions, thread safety	Javadoc specifying what exceptions are thrown when

Comparing interface designs:

PoorInterface.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// ❌ POOR DESIGN
public interface CustomerOperations {
    // Too many unrelated operations
    Customer findById(CustomerId id);
    void save(Customer customer);
    void delete(CustomerId id);
    
    // Why is pricing here?
    Money calculateDiscounts(Customer c);
    List<Promotion> getActivePromotions();
    
    // Why is notification here?
    void sendEmail(Customer c, String msg);
    void sendSms(Customer c, String msg);
    
    // Implementation detail leaked
    Connection getDbConnection();
    
    // Inconsistent abstraction level
    List<Order> getOrders(CustomerId id);
    String getFullName(CustomerId id);
}

GoodInterfaces.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// ✅ GOOD DESIGN
// Focused: only customer persistence
public interface CustomerRepository {
    Customer findById(CustomerId id);
    List<Customer> findBySegment(Segment s);
    void save(Customer customer);
    void delete(CustomerId id);
}
 
// Focused: only discount logic
public interface DiscountService {
    DiscountResult calculate(
        Customer customer, 
        List<CartItem> items
    );
}
 
// Focused: only outbound messaging
public interface NotificationService {
    void notify(Customer c, Notification n);
}
 
// Each interface:
// - Does one thing well
// - Is testable in isolation
// - Can evolve independently

Interface Segregation Principle

Role-Based Interfaces

A powerful interface design technique is to think in terms of roles rather than types. Instead of asking "What can this object do?", ask "What role does this object play in this context?"

Example: A single entity with multiple roles

Consider a User object. In different contexts, it plays different roles:

RoleBasedInterfaces.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
// Role: Something that can be authenticated
public interface AuthenticatedPrincipal {
    String getPrincipalId();
    Set<Permission> getPermissions();
    boolean hasPermission(Permission permission);
}
 
// Role: Something that receives notifications
public interface Notifiable {
    ContactPreferences getContactPreferences();
    String getEmail();
    Optional<String> getPhoneNumber();
}
 
// Role: Something that can purchase
public interface Purchaser {
    PaymentMethod getDefaultPaymentMethod();
    List<PaymentMethod> getSavedPaymentMethods();
    Address getDefaultShippingAddress();
}
 
// Role: Something whose activity can be audited
public interface Auditable {
    String getAuditIdentifier();
    Instant getLastActivityTime();
}
 
// The User class implements all roles it can play
public class User implements AuthenticatedPrincipal, 
                            Notifiable, 
                            Purchaser, 
                            Auditable {
    // Implementation for all roles
}
 
// Consumers depend only on the role they need
public class SecurityService {
    public void checkAccess(AuthenticatedPrincipal principal, Resource resource) {
        if (!principal.hasPermission(resource.requiredPermission())) {
            throw new AccessDeniedException();
        }
    }
    // SecurityService knows nothing about email, payment, etc.
}
 
public class NotificationService {
    public void send(Notifiable recipient, Message message) {
        ContactPreferences prefs = recipient.getContactPreferences();
        if (prefs.prefersEmail()) {
            emailSender.send(recipient.getEmail(), message);
        }
    }
    // NotificationService knows nothing about permissions, payments, etc.
}
 
public class CheckoutService {
    public void checkout(Purchaser purchaser, Cart cart) {
        PaymentMethod method = purchaser.getDefaultPaymentMethod();
        Address shipping = purchaser.getDefaultShippingAddress();
        // CheckoutService knows nothing about permissions, notifications, etc.
    }
}

Benefits of role-based interfaces:

•Minimal knowledge — Each consumer knows only what it needs. SecurityService doesn't know (or care) that principals have email addresses.
•Multiple implementations — Both User and ServiceAccount can implement AuthenticatedPrincipal. Both User and Organization can implement Notifiable.
•Easy testing — Create a simple test implementation of just the role being tested. No need to implement irrelevant methods.
•Flexible composition — New roles can be added without affecting existing interfaces. SubscriptionHolder doesn't impact Notifiable.
•Clear responsibilities — The interface name documents what role the object plays in this context.

Roles vs Types

Interface Composition Patterns

Interfaces can be combined and composed in powerful ways. Understanding these patterns helps you design more flexible systems:

Pattern 1: Interface Inheritance

Extend interfaces to add capabilities:

InterfaceInheritance.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
// Base capability
public interface Repository<T, ID> {
    Optional<T> findById(ID id);
    T save(T entity);
    void delete(ID id);
}
 
// Extended capability
public interface QueryableRepository<T, ID> extends Repository<T, ID> {
    List<T> findAll();
    List<T> findBySpecification(Specification<T> spec);
    Page<T> findPage(PageRequest request);
}
 
// Further extended
public interface AuditableRepository<T, ID> extends Repository<T, ID> {
    List<T> findModifiedAfter(Instant timestamp);
    List<AuditLog> getHistory(ID id);
}
 
// Implementation can choose which level to support
public class UserRepository implements QueryableRepository<User, UserId> {
    // Must implement Repository + QueryableRepository methods
}
 
// Consumer can depend on what they need
public class ReportingService {
    private final QueryableRepository<Order, OrderId> orders;
    // Can use findAll(), findBySpecification(), etc.
}
 
public class SyncService {
    private final AuditableRepository<Product, ProductId> products;
    // Can use findModifiedAfter() for incremental sync
}

Pattern 2: Interface Combination

Implement multiple independent interfaces:

InterfaceCombination.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
// Independent capabilities
public interface Startup {
    void start();
    boolean isRunning();
}
 
public interface Shutdown {
    void shutdown();
    void shutdownNow();
    boolean awaitTermination(Duration timeout);
}
 
public interface HealthCheck {
    HealthStatus checkHealth();
}
 
// Combine for lifecycle-managed components
public interface ManagedService extends Startup, Shutdown, HealthCheck {
    // Inherits all methods from combined interfaces
}
 
// Consumer can work with any combination
public class ServiceManager {
    public void registerService(ManagedService service) {
        services.add(service);
    }
    
    public void startAll() {
        for (ManagedService service : services) {
            service.start();
        }
    }
    
    public HealthReport checkAllHealth() {
        return services.stream()
            .map(s -> s.checkHealth())
            .collect(toHealthReport());
    }
}
 
// Or accept just what's needed
public class HealthMonitor {
    public void register(HealthCheck checkable) {
        // Only needs health checking, not start/stop
        healthChecks.add(checkable);
    }
}

Pattern 3: Marker Interfaces

Signal capabilities without adding methods:

MarkerInterfaces.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// Marker: Indicates safe for concurrent access
public interface ThreadSafe {
    // No methods - merely a marker
}
 
// Marker: Indicates idempotent operations
public interface Idempotent {
    // No methods - signals retry safety
}
 
// Services can be tagged with markers
public class PaymentProcessor implements PaymentGateway, Idempotent {
    // Operations can be safely retried
}
 
public class ConcurrentCache implements Cache, ThreadSafe {
    // Safe for multi-threaded access
}
 
// Generic code can check for markers
public class RetryHandler {
    public <T> T executeWithRetry(Supplier<T> operation, Object service) {
        if (service instanceof Idempotent) {
            return executeWithRetries(operation, 3);
        } else {
            return operation.get(); // Single attempt only
        }
    }
}

Modern Alternative: Annotations

Domain-Driven Interface Design

Contrast: Technical vs Domain Interfaces

TechnicalInterface.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// ❌ TECHNICAL FOCUS
// Named by technology
public interface 
    DatabaseOrderHandler {
    
    // Technical operations
    void insertRow(OrderDto dto);
    ResultSet queryByStatus(
        String status
    );
    void executeTransfer(
        Connection conn, 
        String sql
    );
    
    // Technical return types
    List<Map<String, Object>> 
        executeQuery(String sql);
}

DomainInterface.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// ✅ DOMAIN FOCUS
// Named by domain concept
public interface OrderRepository {
    
    // Domain operations
    Order save(Order order);
    Optional<Order> findById(
        OrderId id
    );
    List<Order> findPending();
    
    // Domain return types
    OrderSummary getSummary(
        OrderId id
    );
    
    // Domain exceptions
    // throws OrderNotFoundException
}

Using Ubiquitous Language:

Domain-driven design emphasizes ubiquitous language—a shared vocabulary used by developers and domain experts. Interfaces should use this language:

UbiquitousLanguage.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
// Domain: E-commerce fulfillment
// The business talks about "fulfilling orders" and "shipping"
 
// ❌ Generic programming terms
public interface ItemHandler {
    void process(ItemDto item);
    void move(ItemDto from, LocationDto to);
}
 
// ✅ Domain terms the business uses
public interface FulfillmentService {
    void fulfillOrder(Order order);              // Business action
    void shipToCustomer(Order order);            // Business action
    PackingSlip generatePackingSlip(Order order);// Business artifact
}
 
// ❌ Technical storage terms
public interface DataStore {
    void insert(Object entity);
    List<Object> query(Predicate pred);
}
 
// ✅ Domain-specific repository
public interface ShipmentRepository {
    Shipment findByTrackingNumber(TrackingNumber number);
    List<Shipment> findInTransit();
    List<Shipment> findDeliveredToday();  // Domain concept
}
 
// ❌ Generic messaging
public interface MessageSender {
    void send(String recipient, String content);
}
 
// ✅ Domain-specific communication
public interface CustomerCommunication {
    void sendShippingNotification(
        Customer customer, 
        Shipment shipment
    );
    void sendDeliveryConfirmation(
        Customer customer, 
        Shipment shipment,
        DeliveryProof proof
    );
}

Talk to Domain Experts

Interface-First Implementation

With interfaces defined, implementation follows. Here's a complete example showing how interface-first design leads to clean, testable code:

The checkout system implementation:

CheckoutImplementation.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
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
// The orchestrating service depends only on interfaces
public class CheckoutService {
    private final PricingService pricing;
    private final InventoryService inventory;
    private final PaymentGateway payments;
    private final OrderRepository orders;
    private final NotificationService notifications;
    
    // Constructor injection of all interfaces
    public CheckoutService(
            PricingService pricing,
            InventoryService inventory,
            PaymentGateway payments,
            OrderRepository orders,
            NotificationService notifications) {
        this.pricing = pricing;
        this.inventory = inventory;
        this.payments = payments;
        this.orders = orders;
        this.notifications = notifications;
    }
    
    public CheckoutResult checkout(Cart cart, Customer customer, 
                                   ShippingOption shipping, 
                                   PaymentMethod paymentMethod) {
        
        // 1. Calculate pricing
        PricingResult price = pricing.calculatePrice(cart, customer, shipping);
        
        // 2. Check & reserve inventory
        AvailabilityResult availability = inventory.checkAvailability(cart.getItems());
        if (!availability.isFullyAvailable()) {
            return CheckoutResult.outOfStock(availability.getUnavailableItems());
        }
        
        ReservationResult reservation = inventory.reserve(
            cart.getItems(), 
            Duration.ofMinutes(10)
        );
        
        try {
            // 3. Authorize payment
            PaymentResult payment = payments.authorize(price.total(), paymentMethod);
            if (!payment.isSuccessful()) {
                inventory.release(reservation.getId());
                notifications.sendOrderFailed(customer, payment.getErrorMessage());
                return CheckoutResult.paymentFailed(payment);
            }
            
            // 4. Create order
            Order order = Order.create(
                cart, 
                customer, 
                shipping, 
                price, 
                payment.getTransactionId()
            );
            Order savedOrder = orders.save(order);
            
            // 5. Capture payment
            payments.capture(payment.getTransactionId());
            
            // 6. Notify customer
            notifications.sendOrderConfirmation(savedOrder, customer);
            
            return CheckoutResult.success(savedOrder);
            
        } catch (Exception e) {
            // Compensating actions
            inventory.release(reservation.getId());
            throw new CheckoutException("Checkout failed", e);
        }
    }
}
 
// Test with fake implementations - no external dependencies
@Test
void checkout_successPath_createsOrderAndNotifies() {
    // Arrange: Simple fakes
    FakePricingService pricing = new FakePricingService(
        PricingResult.of(Money.of(99.99, USD))
    );
    FakeInventoryService inventory = new FakeInventoryService(
        AvailabilityResult.fullyAvailable()
    );
    FakePaymentGateway payments = new FakePaymentGateway(
        PaymentResult.success("TXN-123")
    );
    InMemoryOrderRepository orders = new InMemoryOrderRepository();
    RecordingNotificationService notifications = new RecordingNotificationService();
    
    CheckoutService service = new CheckoutService(
        pricing, inventory, payments, orders, notifications
    );
    
    // Act
    CheckoutResult result = service.checkout(cart, customer, shipping, card);
    
    // Assert
    assertThat(result.isSuccessful()).isTrue();
    assertThat(orders.findAll()).hasSize(1);
    assertThat(notifications.getConfirmationsSent()).hasSize(1);
}

Testing Becomes Trivial

Wiring It All Together

With interfaces designed and implemented, the final step is wiring—connecting implementations to consumers. This typically happens at application startup.

Common wiring approaches:

WiringApproaches.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
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
// ==========================================
// Approach 1: Manual Wiring (Pure Java)
// ==========================================
public class Application {
    public static void main(String[] args) {
        // Create implementations
        PricingService pricing = new StandardPricingService(
            new PromotionRepository(),
            new TaxCalculator()
        );
        InventoryService inventory = new WarehouseInventoryService(
            dataSource,
            redisClient
        );
        PaymentGateway payments = new StripePaymentGateway(
            stripeApiKey,
            webhookSecret
        );
        OrderRepository orders = new PostgresOrderRepository(dataSource);
        NotificationService notifications = new MultiChannelNotifier(
            new SendGridEmailer(apiKey),
            new TwilioSmsService(accountSid, authToken)
        );
        
        // Wire together
        CheckoutService checkout = new CheckoutService(
            pricing, inventory, payments, orders, notifications
        );
        
        // Start application with wired services
        new WebServer(checkout).start();
    }
}
 
// ==========================================
// Approach 2: Dependency Injection Framework (Spring)
// ==========================================
@Configuration
public class CheckoutConfiguration {
    
    @Bean
    public PricingService pricingService(
            PromotionRepository promos, 
            TaxCalculator tax) {
        return new StandardPricingService(promos, tax);
    }
    
    @Bean
    @Profile("production")
    public PaymentGateway productionPayments(
            @Value("${stripe.api.key}") String apiKey) {
        return new StripePaymentGateway(apiKey);
    }
    
    @Bean
    @Profile("development")
    public PaymentGateway developmentPayments() {
        return new FakePaymentGateway(); // No real charges
    }
    
    @Bean
    public CheckoutService checkoutService(
            PricingService pricing,
            InventoryService inventory,
            PaymentGateway payments,
            OrderRepository orders,
            NotificationService notifications) {
        return new CheckoutService(
            pricing, inventory, payments, orders, notifications
        );
    }
}
 
// ==========================================
// Approach 3: Module System (Guice-style)
// ==========================================
public class CheckoutModule extends AbstractModule {
    @Override
    protected void configure() {
        bind(PricingService.class).to(StandardPricingService.class);
        bind(PaymentGateway.class).to(StripePaymentGateway.class);
        bind(OrderRepository.class).to(PostgresOrderRepository.class);
        
        // Conditional binding
        if (isDevelopment()) {
            bind(NotificationService.class).to(LoggingNotifier.class);
        } else {
            bind(NotificationService.class).to(MultiChannelNotifier.class);
        }
    }
}

Wiring Best Practices

•Centralize wiring — Keep configuration in one place (the composition root). Don't scatter new across the codebase.
•Environment-specific implementations — Use profiles or conditions to swap implementations (production Stripe vs development fake).
•Fail fast — Verify all dependencies can be satisfied at startup, not when first used.
•Document the wiring — The composition root shows how the system is assembled. Make it readable.
•Consider performance — In rare cases, interface indirection matters. Wire critical paths thoughtfully.

Summary and Key Takeaways

We've completed our exploration of programming to interfaces with a comprehensive look at interface-based design. Let's consolidate everything we've learned across this module:

Module Key Takeaways

•Depend on abstractions, not implementations — This creates firewalls between components, enabling substitution and testing.
•Interfaces enable flexibility through substitution, decoration, and composition — Requirements change; interface-based designs accommodate change gracefully.
•Loose coupling is achieved through interface boundaries — Components know only contracts, not internals. Changes stay localized.
•Design interfaces first, then implement — This inverts the typical flow and produces cleaner architectures.
•Interfaces should be cohesive and minimal — Single capability, complete abstraction, no leaked implementation details.
•Think in roles, not types — Accept the narrowest interface that provides the needed capability.
•Use domain language in interface design — Interfaces should sound natural to domain experts.
•Composition patterns extend interface power — Inheritance, combination, and markers enable sophisticated designs.
•Wiring connects it all at startup — The composition root assembles implementations, keeping the rest of the code clean.

The principle in action:

"Program to an interface, not an implementation." — Gang of Four, Design Patterns (1994)

Module Complete

4 / 4