System Design (LLD)The Power of Programming to Interfaces

The Power of Programming to Interfaces

LevelIntermediate

Duration60 mins

TopicThe Power of Programming to Interfaces

2 / 4

Flexibility Through Interfaces

When Requirements Evolve

Software requirements change. This isn't a flaw in the development process—it's the nature of building systems for dynamic businesses in evolving markets. The startup that initially processed payments in one country expands globally. The internal tool built for one team gets adopted company-wide. The prototype that "just needs to work" becomes production-critical infrastructure.

The question isn't whether your system will need to change, but how easily it can accommodate change when the time comes. This is where interfaces demonstrate their true power—not as academic abstractions, but as practical enablers of evolution.

In this page, we'll explore concrete patterns for leveraging interfaces to build systems that flex gracefully under changing requirements.

What You Will Learn

By the end of this page, you will understand how interfaces enable flexibility through substitution, composition, and extension. You'll learn practical patterns for designing systems that accommodate change without requiring rewrites of existing code.

The Substitution Principle

The fundamental flexibility that interfaces provide is substitution—the ability to replace one implementation with another without changing the code that uses it. This seems simple, but its implications are profound.

Consider a document storage system:

DocumentStorage.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
/**
 * Abstract contract for document storage operations.
 * Any implementation must fulfill these guarantees.
 */
public interface DocumentStorage {
    
    /**
     * Stores a document and returns a unique identifier.
     * 
     * @param document The document content to store
     * @param metadata Associated metadata (content type, tags, etc.)
     * @return A unique identifier for later retrieval
     * @throws StorageException if storage fails
     */
    DocumentId store(byte[] document, DocumentMetadata metadata);
    
    /**
     * Retrieves a document by its identifier.
     * 
     * @param id The document identifier
     * @return The document content
     * @throws DocumentNotFoundException if the document doesn't exist
     */
    byte[] retrieve(DocumentId id);
    
    /**
     * Checks if a document exists.
     * 
     * @param id The document identifier
     * @return true if the document exists, false otherwise
     */
    boolean exists(DocumentId id);
    
    /**
     * Deletes a document.
     * 
     * @param id The document identifier
     * @throws DocumentNotFoundException if the document doesn't exist
     */
    void delete(DocumentId id);
}

With this interface, we can create multiple implementations:

StorageImplementations.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
// Local filesystem storage - simple, no external dependencies
public class FileSystemStorage implements DocumentStorage {
    private final Path baseDirectory;
    
    @Override
    public DocumentId store(byte[] document, DocumentMetadata metadata) {
        DocumentId id = DocumentId.generate();
        Path filePath = baseDirectory.resolve(id.toString());
        Files.write(filePath, document);
        saveMetadata(filePath.resolveSibling(id + ".meta"), metadata);
        return id;
    }
    
    @Override
    public byte[] retrieve(DocumentId id) {
        Path filePath = baseDirectory.resolve(id.toString());
        if (!Files.exists(filePath)) {
            throw new DocumentNotFoundException(id);
        }
        return Files.readAllBytes(filePath);
    }
    // ... other methods
}
 
// AWS S3 storage - scalable, durable, globally distributed
public class S3Storage implements DocumentStorage {
    private final S3Client s3Client;
    private final String bucketName;
    
    @Override
    public DocumentId store(byte[] document, DocumentMetadata metadata) {
        DocumentId id = DocumentId.generate();
        s3Client.putObject(
            PutObjectRequest.builder()
                .bucket(bucketName)
                .key(id.toString())
                .contentType(metadata.getContentType())
                .metadata(metadata.toMap())
                .build(),
            RequestBody.fromBytes(document)
        );
        return id;
    }
    
    @Override
    public byte[] retrieve(DocumentId id) {
        try {
            return s3Client.getObject(
                GetObjectRequest.builder()
                    .bucket(bucketName)
                    .key(id.toString())
                    .build()
            ).readAllBytes();
        } catch (NoSuchKeyException e) {
            throw new DocumentNotFoundException(id);
        }
    }
    // ... other methods
}
 
// Database BLOB storage - transactional, consistent with other data
public class DatabaseStorage implements DocumentStorage {
    private final JdbcTemplate jdbc;
    
    @Override
    public DocumentId store(byte[] document, DocumentMetadata metadata) {
        DocumentId id = DocumentId.generate();
        jdbc.update(
            "INSERT INTO documents (id, content, metadata, created_at) VALUES (?, ?, ?, ?)",
            id.toString(), 
            document, 
            toJson(metadata), 
            Instant.now()
        );
        return id;
    }
    
    @Override
    public byte[] retrieve(DocumentId id) {
        return jdbc.queryForObject(
            "SELECT content FROM documents WHERE id = ?",
            byte[].class,
            id.toString()
        );
    }
    // ... other methods
}

The consuming code remains unchanged regardless of which implementation is used:

DocumentService.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
public class DocumentService {
    private final DocumentStorage storage;  // Interface, not implementation
    
    public DocumentService(DocumentStorage storage) {
        this.storage = storage;
    }
    
    public DocumentId uploadDocument(InputStream content, String contentType) {
        byte[] bytes = content.readAllBytes();
        DocumentMetadata metadata = DocumentMetadata.builder()
            .contentType(contentType)
            .uploadedAt(Instant.now())
            .checksum(computeChecksum(bytes))
            .build();
        
        return storage.store(bytes, metadata);
    }
    
    public Document getDocument(DocumentId id) {
        if (!storage.exists(id)) {
            throw new DocumentNotFoundException(id);
        }
        return new Document(id, storage.retrieve(id));
    }
}
 
// Configuration determines which storage is injected:
 
// Development - use local filesystem
@Profile("development")
@Bean
public DocumentStorage developmentStorage() {
    return new FileSystemStorage(Path.of("./dev-documents"));
}
 
// Production - use S3
@Profile("production")
@Bean
public DocumentStorage productionStorage(S3Client s3) {
    return new S3Storage(s3, "company-documents-prod");
}
 
// Legacy integration - use database
@Profile("legacy")
@Bean
public DocumentStorage legacyStorage(JdbcTemplate jdbc) {
    return new DatabaseStorage(jdbc);
}

Substitution Without Modification

Notice that DocumentService never changes when we switch storage implementations. The same compiled code works with filesystem, S3, or database storage. This is the essence of interface-driven flexibility: the same code behaves differently based on the injected implementation.

Runtime Flexibility Patterns

Beyond simple substitution, interfaces enable sophisticated runtime flexibility patterns. Let's explore the most powerful ones:

Pattern 1: Strategy Selection

Different situations call for different algorithms. Interfaces allow selecting the appropriate strategy at runtime:

StrategySelection.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
public interface CompressionStrategy {
    byte[] compress(byte[] data);
    byte[] decompress(byte[] compressed);
    String getAlgorithmName();
}
 
public class GzipCompression implements CompressionStrategy {
    public byte[] compress(byte[] data) {
        // GZIP implementation - good compression, moderate speed
    }
}
 
public class LZ4Compression implements CompressionStrategy {
    public byte[] compress(byte[] data) {
        // LZ4 implementation - fast compression, moderate ratio
    }
}
 
public class ZstdCompression implements CompressionStrategy {
    public byte[] compress(byte[] data) {
        // Zstandard implementation - excellent compression, good speed
    }
}
 
// Runtime selection based on requirements:
public class DocumentCompressor {
    private final Map<CompressionGoal, CompressionStrategy> strategies;
    
    public DocumentCompressor() {
        this.strategies = Map.of(
            CompressionGoal.MINIMIZE_SIZE, new ZstdCompression(),
            CompressionGoal.MAXIMIZE_SPEED, new LZ4Compression(),
            CompressionGoal.BROAD_COMPATIBILITY, new GzipCompression()
        );
    }
    
    public byte[] compress(byte[] document, CompressionGoal goal) {
        CompressionStrategy strategy = strategies.get(goal);
        return strategy.compress(document);
    }
}

Pattern 2: Feature Toggles

Interfaces enable clean feature toggle implementations where behavior can be switched without code changes:

FeatureToggles.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
public interface SearchEngine {
    SearchResults search(SearchQuery query);
}
 
// Current production implementation
public class ElasticsearchEngine implements SearchEngine {
    public SearchResults search(SearchQuery query) {
        // Full Elasticsearch implementation
    }
}
 
// New implementation being developed
public class VectorSearchEngine implements SearchEngine {
    public SearchResults search(SearchQuery query) {
        // AI-powered vector similarity search
    }
}
 
// Feature toggle bridge
public class ToggleableSearchEngine implements SearchEngine {
    private final SearchEngine production;
    private final SearchEngine experimental;
    private final FeatureFlags flags;
    
    public SearchResults search(SearchQuery query) {
        if (flags.isEnabled("vector-search", query.getUserId())) {
            return experimental.search(query);
        }
        return production.search(query);
    }
}
 
// Usage: 1% of users get the new search experience
FeatureFlags flags = new PercentageRollout("vector-search", 1);
SearchEngine engine = new ToggleableSearchEngine(
    elasticsearchEngine,
    vectorSearchEngine,
    flags
);

Pattern 3: Composite Behavior

Multiple implementations can be combined to create aggregate behavior:

CompositeBehavior.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
public interface NotificationChannel {
    void send(User user, Message message);
    boolean supportsUser(User user);
}
 
// Individual channels
public class EmailChannel implements NotificationChannel { ... }
public class SMSChannel implements NotificationChannel { ... }
public class PushChannel implements NotificationChannel { ... }
public class SlackChannel implements NotificationChannel { ... }
 
// Composite: send to all applicable channels
public class MultiChannelNotifier implements NotificationChannel {
    private final List<NotificationChannel> channels;
    
    public MultiChannelNotifier(List<NotificationChannel> channels) {
        this.channels = new ArrayList<>(channels);
    }
    
    @Override
    public void send(User user, Message message) {
        for (NotificationChannel channel : channels) {
            if (channel.supportsUser(user)) {
                try {
                    channel.send(user, message);
                } catch (NotificationException e) {
                    // Log failure, continue with other channels
                    log.warn("Failed to send via {}", channel, e);
                }
            }
        }
    }
    
    @Override
    public boolean supportsUser(User user) {
        return channels.stream().anyMatch(c -> c.supportsUser(user));
    }
}
 
// Configuration binds user preferences to channels
MultiChannelNotifier notifier = new MultiChannelNotifier(List.of(
    emailChannel,     // Always included
    smsChannel,       // For users with phone numbers
    pushChannel,      // For users with mobile apps
    slackChannel      // For internal users
));

Composite Pattern

The MultiChannelNotifier is an example of the Composite pattern—an object that implements an interface while containing other objects of the same interface. This works only because we designed to interfaces; consumers treat the composite exactly like any single channel.

The Power of Decoration

One of the most powerful flexibility patterns enabled by interfaces is the Decorator pattern—wrapping an implementation to add behavior without modifying it.

The core insight: A decorator implements the same interface as the object it wraps, adding functionality before or after delegating to the wrapped object. This allows stacking behaviors like layers:

Example: Enhancing a Cache

CacheDecorators.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
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
public interface Cache<K, V> {
    V get(K key);
    void put(K key, V value);
    void invalidate(K key);
}
 
// Base implementation: simple in-memory cache
public class InMemoryCache<K, V> implements Cache<K, V> {
    private final Map<K, V> store = new ConcurrentHashMap<>();
    
    @Override
    public V get(K key) {
        return store.get(key);
    }
    
    @Override
    public void put(K key, V value) {
        store.put(key, value);
    }
    
    @Override
    public void invalidate(K key) {
        store.remove(key);
    }
}
 
// Decorator 1: Add metrics collection
public class InstrumentedCache<K, V> implements Cache<K, V> {
    private final Cache<K, V> delegate;
    private final MetricsCollector metrics;
    
    public InstrumentedCache(Cache<K, V> delegate, MetricsCollector metrics) {
        this.delegate = delegate;
        this.metrics = metrics;
    }
    
    @Override
    public V get(K key) {
        long start = System.nanoTime();
        try {
            V value = delegate.get(key);
            if (value != null) {
                metrics.recordCacheHit();
            } else {
                metrics.recordCacheMiss();
            }
            return value;
        } finally {
            metrics.recordLatency("cache.get", System.nanoTime() - start);
        }
    }
    
    @Override
    public void put(K key, V value) {
        long start = System.nanoTime();
        try {
            delegate.put(key, value);
        } finally {
            metrics.recordLatency("cache.put", System.nanoTime() - start);
        }
    }
    
    @Override
    public void invalidate(K key) {
        delegate.invalidate(key);
        metrics.recordInvalidation();
    }
}
 
// Decorator 2: Add logging
public class LoggingCache<K, V> implements Cache<K, V> {
    private final Cache<K, V> delegate;
    private final Logger logger;
    
    @Override
    public V get(K key) {
        logger.debug("Cache lookup: key={}", key);
        V value = delegate.get(key);
        logger.debug("Cache result: key={}, found={}", key, value != null);
        return value;
    }
    
    @Override
    public void put(K key, V value) {
        logger.debug("Cache store: key={}", key);
        delegate.put(key, value);
    }
    
    @Override
    public void invalidate(K key) {
        logger.info("Cache invalidation: key={}", key);
        delegate.invalidate(key);
    }
}
 
// Decorator 3: Add TTL (time-to-live) support
public class TTLCache<K, V> implements Cache<K, V> {
    private final Cache<K, TimestampedValue<V>> delegate;
    private final Duration ttl;
    private final Clock clock;
    
    @Override
    public V get(K key) {
        TimestampedValue<V> entry = delegate.get(key);
        if (entry == null) {
            return null;
        }
        if (isExpired(entry)) {
            delegate.invalidate(key);
            return null;
        }
        return entry.getValue();
    }
    
    @Override
    public void put(K key, V value) {
        delegate.put(key, new TimestampedValue<>(value, clock.instant()));
    }
    
    private boolean isExpired(TimestampedValue<V> entry) {
        return Duration.between(entry.getTimestamp(), clock.instant())
                       .compareTo(ttl) > 0;
    }
}

The magical part—compositional stacking:

DecoratorComposition.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// Start with the base cache
Cache<UserId, UserProfile> base = new InMemoryCache<>();
 
// Add TTL expiration
Cache<UserId, UserProfile> withTTL = new TTLCache<>(base, Duration.ofMinutes(10));
 
// Add metrics
Cache<UserId, UserProfile> withMetrics = new InstrumentedCache<>(withTTL, metrics);
 
// Add logging for production debugging
Cache<UserId, UserProfile> production = new LoggingCache<>(withMetrics, logger);
 
// The final cache has all behaviors:
// - In-memory storage (base)
// - 10-minute TTL expiration
// - Metrics collection  
// - Debug logging
 
// But it's still just a Cache<K, V> to consumers:
UserService userService = new UserService(production);

Decorator Order Matters

The order of decorators affects behavior. In our example, metrics are recorded for the TTL-checked operations (including the 'miss' when TTL expires). If we reversed the order, expired entries would first be logged as 'found' before the TTL check. Design decorator stacking carefully.

Why decoration is powerful:

Single Responsibility — Each decorator does exactly one thing. Logging knows nothing about TTL. Metrics know nothing about logging.
Open for Extension — Adding new behaviors (encryption, replication, circuit breaking) requires only new decorators, not modifying existing code.
Configurable Composition — Different environments can use different decorator stacks. Development might skip metrics; production might skip verbose logging.
Testable in Isolation — Each decorator can be tested independently with a mock delegate. The TTLCache tests don't need real metrics.

Interface-Defined Extension Points

Interfaces allow you to define extension points—places where the system explicitly invites new behavior to be plugged in. This turns modification requests into addition requests.

Example: An Extensible Validation System

ValidationExtensionPoints.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
/**
 * Extension point: implement this interface to add custom validation rules.
 */
public interface OrderValidator {
    /**
     * Validates an order before processing.
     * 
     * @param order The order to validate
     * @return ValidationResult containing any errors or warnings
     */
    ValidationResult validate(Order order);
    
    /**
     * Indicates the priority of this validator.
     * Lower values run first.
     */
    default int priority() {
        return 100; // Default priority
    }
}
 
// Core validators - shipped with the system
public class InventoryValidator implements OrderValidator {
    public ValidationResult validate(Order order) {
        for (OrderItem item : order.getItems()) {
            int available = inventory.getAvailable(item.getProductId());
            if (available < item.getQuantity()) {
                return ValidationResult.error(
                    "Insufficient inventory for " + item.getProductId()
                );
            }
        }
        return ValidationResult.valid();
    }
    
    public int priority() { return 10; } // Run early
}
 
public class PaymentValidator implements OrderValidator {
    public ValidationResult validate(Order order) {
        if (!paymentService.canCharge(order.getPaymentMethod())) {
            return ValidationResult.error("Payment method declined");
        }
        return ValidationResult.valid();
    }
    
    public int priority() { return 50; }
}
 
// Custom validators - added by specific business units
public class FraudDetectionValidator implements OrderValidator {
    public ValidationResult validate(Order order) {
        RiskScore risk = fraudService.assessRisk(order);
        if (risk.isHighRisk()) {
            return ValidationResult.error("Order flagged for fraud review");
        }
        if (risk.isMediumRisk()) {
            return ValidationResult.warning("Order requires manual approval");
        }
        return ValidationResult.valid();
    }
    
    public int priority() { return 5; } // Run first
}
 
public class ExportComplianceValidator implements OrderValidator {
    public ValidationResult validate(Order order) {
        if (requiresExportLicense(order) && !hasExportLicense(order)) {
            return ValidationResult.error("Export license required");
        }
        return ValidationResult.valid();
    }
}

The validation engine uses all registered validators:

ValidationEngine.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
public class OrderValidationEngine {
    private final List<OrderValidator> validators;
    
    // Validators are injected - the engine doesn't know concrete types
    public OrderValidationEngine(List<OrderValidator> validators) {
        // Sort by priority
        this.validators = validators.stream()
            .sorted(Comparator.comparingInt(OrderValidator::priority))
            .collect(toList());
    }
    
    public ValidationResult validateOrder(Order order) {
        List<String> errors = new ArrayList<>();
        List<String> warnings = new ArrayList<>();
        
        for (OrderValidator validator : validators) {
            ValidationResult result = validator.validate(order);
            
            if (result.hasErrors()) {
                errors.addAll(result.getErrors());
                if (shouldStopOnError()) {
                    break; // Fail fast
                }
            }
            warnings.addAll(result.getWarnings());
        }
        
        return new ValidationResult(errors, warnings);
    }
}
 
// Registration via framework (Spring example):
@Configuration
public class ValidationConfig {
    @Bean
    public OrderValidationEngine engine(List<OrderValidator> validators) {
        // All @Component classes implementing OrderValidator are auto-discovered
        return new OrderValidationEngine(validators);
    }
}
 
// Adding new validation is just adding a new class:
@Component
public class LoyaltyTierValidator implements OrderValidator {
    // Automatically included in validation without changing any existing code
}

Plugin Architecture

This pattern is the foundation of plugin architectures. Eclipse, VS Code, Webpack, and countless other tools use it. The core system defines interfaces; extensions implement them. The core doesn't know about specific plugins—only about the interface they implement.

Flexibility Without Prediction

A common objection to interface-based design is: "How can I create the right interface if I don't know what implementations I'll need?"

The answer is that you don't need to predict specific implementations—you need to identify natural boundaries where variation is likely or valuable.

Reliable boundaries for abstraction:

Where to Introduce Interfaces

•External dependencies — Database, file storage, network services, third-party APIs. These almost always have alternative implementations (testing, vendor changes, migration).
•Cross-cutting concerns — Logging, metrics, authentication, caching. Different environments and contexts need different implementations.
•Behavioral policies — Retry logic, timeout handling, circuit breaking. Business requirements dictate different policies.
•Domain strategies — Pricing calculations, discount rules, shipping estimation. Business logic evolves frequently.
•Output channels — Email, SMS, push notifications, webhooks. The set of channels expands over time.
•Input sources — REST APIs, GraphQL, message queues, file imports. Systems acquire new integration points.

Designing interfaces at these boundaries follows a pattern:

Identify the capability — What action does the consuming code need? ("store a document," "send a notification," "compute shipping cost")
Define the contract — What inputs are required? What outputs are expected? What errors can occur?
Keep it minimal — Include only what consumers need. Avoid exposing implementation details.
Name it by purpose — DocumentStorage, not S3Wrapper. NotificationChannel, not TwilioService.

BoundaryInterface.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// Good: named by capability, minimal surface
public interface ShippingCalculator {
    ShippingQuote calculateShipping(
        Address origin,
        Address destination,
        List<Package> packages
    );
}
 
// The interface doesn't expose:
// - Which carrier is used
// - API authentication details
// - Rate negotiation logic
// - Caching strategies
 
// Any of these implementations work:
public class UPSShippingCalculator implements ShippingCalculator { ... }
public class FedExShippingCalculator implements ShippingCalculator { ... }
public class MultiCarrierCalculator implements ShippingCalculator { ... }
public class MockShippingCalculator implements ShippingCalculator { ... }

You Don't Need to Be Right on the First Try

If you introduce an interface at a boundary and later find you only ever have one implementation, you've lost almost nothing—just a tiny bit of indirection. But if you hard-code a concrete dependency and later need flexibility, refactoring is expensive. When in doubt at natural boundaries, prefer abstraction.

Interface Evolution Strategies

Interfaces provide flexibility, but they themselves must sometimes evolve. How do you add capabilities to an interface without breaking existing implementations?

Strategy 1: Default Methods (Java 8+, C# 8+)

Modern languages allow interfaces to include default implementations:

DefaultMethods.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
public interface MessageQueue {
    // Original methods - must be implemented
    void send(Message message);
    Message receive();
    
    // New method with default implementation
    // Existing implementations continue working
    default void sendBatch(List<Message> messages) {
        for (Message message : messages) {
            send(message);
        }
    }
    
    // New method with sensible default
    default int getPendingCount() {
        return -1; // Unknown
    }
}
 
// Existing implementations still work - they inherit defaults
public class RabbitMQQueue implements MessageQueue {
    public void send(Message message) { ... }
    public Message receive() { ... }
    // sendBatch() and getPendingCount() are inherited
}
 
// New implementations can override for better behavior
public class KafkaQueue implements MessageQueue {
    public void send(Message message) { ... }
    public Message receive() { ... }
    
    @Override
    public void sendBatch(List<Message> messages) {
        // Kafka-optimized batch sending
        producer.send(messages);
    }
    
    @Override
    public int getPendingCount() {
        return consumer.lag();
    }
}

Strategy 2: Interface Segregation

Instead of growing a single interface, split capabilities into focused interfaces:

InterfaceSegregation.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
// Original interface
public interface MessageQueue {
    void send(Message message);
    Message receive();
}
 
// Additional capability as separate interface
public interface BatchMessageQueue extends MessageQueue {
    void sendBatch(List<Message> messages);
}
 
// Another capability
public interface ObservableQueue extends MessageQueue {
    int getPendingCount();
    void addListener(QueueListener listener);
}
 
// Implementations declare which capabilities they support
public class KafkaQueue implements BatchMessageQueue, ObservableQueue {
    // Supports all capabilities
}
 
public class SimpleQueue implements MessageQueue {
    // Supports only basic operations
}
 
// Consumers depend only on what they need
public class BasicProcessor {
    private final MessageQueue queue;  // Only needs basic ops
}
 
public class BatchProcessor {
    private final BatchMessageQueue queue;  // Needs batch capability
}

Strategy 3: Versioned Interfaces

For major changes, create new versions while maintaining backward compatibility:

VersionedInterfaces.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
// Original interface - still supported
public interface PaymentProcessor {
    PaymentResult process(PaymentRequest request);
}
 
// New version with enhanced capabilities
public interface PaymentProcessorV2 extends PaymentProcessor {
    PaymentResult processWithMetadata(
        PaymentRequest request,
        PaymentMetadata metadata
    );
    
    boolean supports3DSecure();
    
    PaymentResult process3DSecure(
        PaymentRequest request,
        ThreeDSecureData secureData
    );
}
 
// Adapter for legacy implementations
public class PaymentProcessorV2Adapter implements PaymentProcessorV2 {
    private final PaymentProcessor legacy;
    
    @Override
    public PaymentResult process(PaymentRequest request) {
        return legacy.process(request);
    }
    
    @Override
    public PaymentResult processWithMetadata(
            PaymentRequest request, PaymentMetadata metadata) {
        // Metadata ignored - legacy doesn't support it
        log.warn("Metadata ignored by legacy processor");
        return legacy.process(request);
    }
    
    @Override
    public boolean supports3DSecure() {
        return false;
    }
    
    @Override
    public PaymentResult process3DSecure(
            PaymentRequest request, ThreeDSecureData secureData) {
        throw new UnsupportedOperationException("Legacy processor");
    }
}

Breaking Changes Are Expensive

Changing an existing interface method signature breaks all implementations and all callers. This ripple effect is why interfaces should be designed carefully upfront and evolved conservatively. The strategies above—default methods, segregation, and versioning—minimize breaking changes.

Practical Guidelines

Based on the patterns we've explored, here are practical guidelines for leveraging interfaces effectively:

Interface Design Best Practices
Guideline	Rationale	Example
Name interfaces by capability, not implementation	Names should survive implementation changes	`DocumentStorage`, not `S3DocumentStorage`
Keep interfaces small and focused	Smaller interfaces are easier to implement and compose	Split `UserRepository` from `UserQueryService`
Define clear contracts with documentation	Implementations need unambiguous requirements	Document exceptions, null handling, threading
Include only what consumers need	Extra methods become implementation burdens	Don't add `getConnectionPool()` to `Database`
Prefer composition over large interfaces	Composed small interfaces are more flexible	`interface Pageable`, `interface Sortable`
Add new methods with default implementations	Preserves backward compatibility	`default void close() { }`

Common patterns for specific scenarios:

•Need to switch implementations at runtime? — Use Strategy pattern with interface-typed field
•Need to add behavior without modification? — Use Decorator pattern wrapping the interface
•Need to combine multiple implementations? — Use Composite pattern with collection of interface instances
•Need gradual rollout of new implementation? — Use feature toggle wrapping interface selection
•Need to support optional capabilities? — Extend base interface or use interface segregation
•Need graceful degradation? — Chain implementations with fallback logic

Summary and Key Takeaways

We've explored how interfaces enable genuine flexibility in software systems—not just theoretical abstraction, but practical patterns that solve real evolution challenges. Let's consolidate the key lessons:

Key Takeaways

•Substitution is the core flexibility — Interfaces allow replacing one implementation with another without changing consuming code. This enables environment-specific behavior, vendor switching, and testing.
•Runtime flexibility patterns abound — Strategy selection, feature toggles, and composite behaviors are all enabled by programming to interfaces rather than implementations.
•Decoration adds behavior without modification — The Decorator pattern stacks capabilities (metrics, logging, caching, retry) around implementations without changing them.
•Interfaces define extension points — Plugin architectures and extensible systems are built by defining interfaces that extensions implement.
•You don't need to predict—just identify boundaries — External dependencies, cross-cutting concerns, and domain policies are natural abstraction points.
•Interfaces can evolve safely — Default methods, interface segregation, and versioning allow adding capabilities without breaking existing code.
•Small, focused interfaces compose better — Multiple small interfaces are more flexible than one large interface.

What's next:

We've seen how interfaces create flexibility. But flexibility can come with tradeoffs—tight coupling between components, difficulty in testing, and resistance to change. The next page explores how interfaces reduce coupling, creating systems where components are more independent and changes are more localized.

Page Complete

You now understand how interfaces enable flexible systems through substitution, decoration, composition, and extension points. These patterns form the foundation of adaptable software architecture. Next, we'll see how this same approach reduces coupling between system components.

2 / 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

2 / 4

Flexibility Through Interfaces

When Requirements Evolve

In this page, we'll explore concrete patterns for leveraging interfaces to build systems that flex gracefully under changing requirements.

What You Will Learn

The Substitution Principle

Consider a document storage system:

DocumentStorage.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
/**
 * Abstract contract for document storage operations.
 * Any implementation must fulfill these guarantees.
 */
public interface DocumentStorage {
    
    /**
     * Stores a document and returns a unique identifier.
     * 
     * @param document The document content to store
     * @param metadata Associated metadata (content type, tags, etc.)
     * @return A unique identifier for later retrieval
     * @throws StorageException if storage fails
     */
    DocumentId store(byte[] document, DocumentMetadata metadata);
    
    /**
     * Retrieves a document by its identifier.
     * 
     * @param id The document identifier
     * @return The document content
     * @throws DocumentNotFoundException if the document doesn't exist
     */
    byte[] retrieve(DocumentId id);
    
    /**
     * Checks if a document exists.
     * 
     * @param id The document identifier
     * @return true if the document exists, false otherwise
     */
    boolean exists(DocumentId id);
    
    /**
     * Deletes a document.
     * 
     * @param id The document identifier
     * @throws DocumentNotFoundException if the document doesn't exist
     */
    void delete(DocumentId id);
}

With this interface, we can create multiple implementations:

StorageImplementations.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
// Local filesystem storage - simple, no external dependencies
public class FileSystemStorage implements DocumentStorage {
    private final Path baseDirectory;
    
    @Override
    public DocumentId store(byte[] document, DocumentMetadata metadata) {
        DocumentId id = DocumentId.generate();
        Path filePath = baseDirectory.resolve(id.toString());
        Files.write(filePath, document);
        saveMetadata(filePath.resolveSibling(id + ".meta"), metadata);
        return id;
    }
    
    @Override
    public byte[] retrieve(DocumentId id) {
        Path filePath = baseDirectory.resolve(id.toString());
        if (!Files.exists(filePath)) {
            throw new DocumentNotFoundException(id);
        }
        return Files.readAllBytes(filePath);
    }
    // ... other methods
}
 
// AWS S3 storage - scalable, durable, globally distributed
public class S3Storage implements DocumentStorage {
    private final S3Client s3Client;
    private final String bucketName;
    
    @Override
    public DocumentId store(byte[] document, DocumentMetadata metadata) {
        DocumentId id = DocumentId.generate();
        s3Client.putObject(
            PutObjectRequest.builder()
                .bucket(bucketName)
                .key(id.toString())
                .contentType(metadata.getContentType())
                .metadata(metadata.toMap())
                .build(),
            RequestBody.fromBytes(document)
        );
        return id;
    }
    
    @Override
    public byte[] retrieve(DocumentId id) {
        try {
            return s3Client.getObject(
                GetObjectRequest.builder()
                    .bucket(bucketName)
                    .key(id.toString())
                    .build()
            ).readAllBytes();
        } catch (NoSuchKeyException e) {
            throw new DocumentNotFoundException(id);
        }
    }
    // ... other methods
}
 
// Database BLOB storage - transactional, consistent with other data
public class DatabaseStorage implements DocumentStorage {
    private final JdbcTemplate jdbc;
    
    @Override
    public DocumentId store(byte[] document, DocumentMetadata metadata) {
        DocumentId id = DocumentId.generate();
        jdbc.update(
            "INSERT INTO documents (id, content, metadata, created_at) VALUES (?, ?, ?, ?)",
            id.toString(), 
            document, 
            toJson(metadata), 
            Instant.now()
        );
        return id;
    }
    
    @Override
    public byte[] retrieve(DocumentId id) {
        return jdbc.queryForObject(
            "SELECT content FROM documents WHERE id = ?",
            byte[].class,
            id.toString()
        );
    }
    // ... other methods
}

The consuming code remains unchanged regardless of which implementation is used:

DocumentService.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
public class DocumentService {
    private final DocumentStorage storage;  // Interface, not implementation
    
    public DocumentService(DocumentStorage storage) {
        this.storage = storage;
    }
    
    public DocumentId uploadDocument(InputStream content, String contentType) {
        byte[] bytes = content.readAllBytes();
        DocumentMetadata metadata = DocumentMetadata.builder()
            .contentType(contentType)
            .uploadedAt(Instant.now())
            .checksum(computeChecksum(bytes))
            .build();
        
        return storage.store(bytes, metadata);
    }
    
    public Document getDocument(DocumentId id) {
        if (!storage.exists(id)) {
            throw new DocumentNotFoundException(id);
        }
        return new Document(id, storage.retrieve(id));
    }
}
 
// Configuration determines which storage is injected:
 
// Development - use local filesystem
@Profile("development")
@Bean
public DocumentStorage developmentStorage() {
    return new FileSystemStorage(Path.of("./dev-documents"));
}
 
// Production - use S3
@Profile("production")
@Bean
public DocumentStorage productionStorage(S3Client s3) {
    return new S3Storage(s3, "company-documents-prod");
}
 
// Legacy integration - use database
@Profile("legacy")
@Bean
public DocumentStorage legacyStorage(JdbcTemplate jdbc) {
    return new DatabaseStorage(jdbc);
}

Substitution Without Modification

Runtime Flexibility Patterns

Beyond simple substitution, interfaces enable sophisticated runtime flexibility patterns. Let's explore the most powerful ones:

Pattern 1: Strategy Selection

Different situations call for different algorithms. Interfaces allow selecting the appropriate strategy at runtime:

StrategySelection.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
public interface CompressionStrategy {
    byte[] compress(byte[] data);
    byte[] decompress(byte[] compressed);
    String getAlgorithmName();
}
 
public class GzipCompression implements CompressionStrategy {
    public byte[] compress(byte[] data) {
        // GZIP implementation - good compression, moderate speed
    }
}
 
public class LZ4Compression implements CompressionStrategy {
    public byte[] compress(byte[] data) {
        // LZ4 implementation - fast compression, moderate ratio
    }
}
 
public class ZstdCompression implements CompressionStrategy {
    public byte[] compress(byte[] data) {
        // Zstandard implementation - excellent compression, good speed
    }
}
 
// Runtime selection based on requirements:
public class DocumentCompressor {
    private final Map<CompressionGoal, CompressionStrategy> strategies;
    
    public DocumentCompressor() {
        this.strategies = Map.of(
            CompressionGoal.MINIMIZE_SIZE, new ZstdCompression(),
            CompressionGoal.MAXIMIZE_SPEED, new LZ4Compression(),
            CompressionGoal.BROAD_COMPATIBILITY, new GzipCompression()
        );
    }
    
    public byte[] compress(byte[] document, CompressionGoal goal) {
        CompressionStrategy strategy = strategies.get(goal);
        return strategy.compress(document);
    }
}

Pattern 2: Feature Toggles

Interfaces enable clean feature toggle implementations where behavior can be switched without code changes:

FeatureToggles.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
public interface SearchEngine {
    SearchResults search(SearchQuery query);
}
 
// Current production implementation
public class ElasticsearchEngine implements SearchEngine {
    public SearchResults search(SearchQuery query) {
        // Full Elasticsearch implementation
    }
}
 
// New implementation being developed
public class VectorSearchEngine implements SearchEngine {
    public SearchResults search(SearchQuery query) {
        // AI-powered vector similarity search
    }
}
 
// Feature toggle bridge
public class ToggleableSearchEngine implements SearchEngine {
    private final SearchEngine production;
    private final SearchEngine experimental;
    private final FeatureFlags flags;
    
    public SearchResults search(SearchQuery query) {
        if (flags.isEnabled("vector-search", query.getUserId())) {
            return experimental.search(query);
        }
        return production.search(query);
    }
}
 
// Usage: 1% of users get the new search experience
FeatureFlags flags = new PercentageRollout("vector-search", 1);
SearchEngine engine = new ToggleableSearchEngine(
    elasticsearchEngine,
    vectorSearchEngine,
    flags
);

Pattern 3: Composite Behavior

Multiple implementations can be combined to create aggregate behavior:

CompositeBehavior.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
public interface NotificationChannel {
    void send(User user, Message message);
    boolean supportsUser(User user);
}
 
// Individual channels
public class EmailChannel implements NotificationChannel { ... }
public class SMSChannel implements NotificationChannel { ... }
public class PushChannel implements NotificationChannel { ... }
public class SlackChannel implements NotificationChannel { ... }
 
// Composite: send to all applicable channels
public class MultiChannelNotifier implements NotificationChannel {
    private final List<NotificationChannel> channels;
    
    public MultiChannelNotifier(List<NotificationChannel> channels) {
        this.channels = new ArrayList<>(channels);
    }
    
    @Override
    public void send(User user, Message message) {
        for (NotificationChannel channel : channels) {
            if (channel.supportsUser(user)) {
                try {
                    channel.send(user, message);
                } catch (NotificationException e) {
                    // Log failure, continue with other channels
                    log.warn("Failed to send via {}", channel, e);
                }
            }
        }
    }
    
    @Override
    public boolean supportsUser(User user) {
        return channels.stream().anyMatch(c -> c.supportsUser(user));
    }
}
 
// Configuration binds user preferences to channels
MultiChannelNotifier notifier = new MultiChannelNotifier(List.of(
    emailChannel,     // Always included
    smsChannel,       // For users with phone numbers
    pushChannel,      // For users with mobile apps
    slackChannel      // For internal users
));

Composite Pattern

The Power of Decoration

One of the most powerful flexibility patterns enabled by interfaces is the Decorator pattern—wrapping an implementation to add behavior without modifying it.

Example: Enhancing a Cache

CacheDecorators.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
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
public interface Cache<K, V> {
    V get(K key);
    void put(K key, V value);
    void invalidate(K key);
}
 
// Base implementation: simple in-memory cache
public class InMemoryCache<K, V> implements Cache<K, V> {
    private final Map<K, V> store = new ConcurrentHashMap<>();
    
    @Override
    public V get(K key) {
        return store.get(key);
    }
    
    @Override
    public void put(K key, V value) {
        store.put(key, value);
    }
    
    @Override
    public void invalidate(K key) {
        store.remove(key);
    }
}
 
// Decorator 1: Add metrics collection
public class InstrumentedCache<K, V> implements Cache<K, V> {
    private final Cache<K, V> delegate;
    private final MetricsCollector metrics;
    
    public InstrumentedCache(Cache<K, V> delegate, MetricsCollector metrics) {
        this.delegate = delegate;
        this.metrics = metrics;
    }
    
    @Override
    public V get(K key) {
        long start = System.nanoTime();
        try {
            V value = delegate.get(key);
            if (value != null) {
                metrics.recordCacheHit();
            } else {
                metrics.recordCacheMiss();
            }
            return value;
        } finally {
            metrics.recordLatency("cache.get", System.nanoTime() - start);
        }
    }
    
    @Override
    public void put(K key, V value) {
        long start = System.nanoTime();
        try {
            delegate.put(key, value);
        } finally {
            metrics.recordLatency("cache.put", System.nanoTime() - start);
        }
    }
    
    @Override
    public void invalidate(K key) {
        delegate.invalidate(key);
        metrics.recordInvalidation();
    }
}
 
// Decorator 2: Add logging
public class LoggingCache<K, V> implements Cache<K, V> {
    private final Cache<K, V> delegate;
    private final Logger logger;
    
    @Override
    public V get(K key) {
        logger.debug("Cache lookup: key={}", key);
        V value = delegate.get(key);
        logger.debug("Cache result: key={}, found={}", key, value != null);
        return value;
    }
    
    @Override
    public void put(K key, V value) {
        logger.debug("Cache store: key={}", key);
        delegate.put(key, value);
    }
    
    @Override
    public void invalidate(K key) {
        logger.info("Cache invalidation: key={}", key);
        delegate.invalidate(key);
    }
}
 
// Decorator 3: Add TTL (time-to-live) support
public class TTLCache<K, V> implements Cache<K, V> {
    private final Cache<K, TimestampedValue<V>> delegate;
    private final Duration ttl;
    private final Clock clock;
    
    @Override
    public V get(K key) {
        TimestampedValue<V> entry = delegate.get(key);
        if (entry == null) {
            return null;
        }
        if (isExpired(entry)) {
            delegate.invalidate(key);
            return null;
        }
        return entry.getValue();
    }
    
    @Override
    public void put(K key, V value) {
        delegate.put(key, new TimestampedValue<>(value, clock.instant()));
    }
    
    private boolean isExpired(TimestampedValue<V> entry) {
        return Duration.between(entry.getTimestamp(), clock.instant())
                       .compareTo(ttl) > 0;
    }
}

The magical part—compositional stacking:

DecoratorComposition.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// Start with the base cache
Cache<UserId, UserProfile> base = new InMemoryCache<>();
 
// Add TTL expiration
Cache<UserId, UserProfile> withTTL = new TTLCache<>(base, Duration.ofMinutes(10));
 
// Add metrics
Cache<UserId, UserProfile> withMetrics = new InstrumentedCache<>(withTTL, metrics);
 
// Add logging for production debugging
Cache<UserId, UserProfile> production = new LoggingCache<>(withMetrics, logger);
 
// The final cache has all behaviors:
// - In-memory storage (base)
// - 10-minute TTL expiration
// - Metrics collection  
// - Debug logging
 
// But it's still just a Cache<K, V> to consumers:
UserService userService = new UserService(production);

Decorator Order Matters

Why decoration is powerful:

Single Responsibility — Each decorator does exactly one thing. Logging knows nothing about TTL. Metrics know nothing about logging.
Open for Extension — Adding new behaviors (encryption, replication, circuit breaking) requires only new decorators, not modifying existing code.
Configurable Composition — Different environments can use different decorator stacks. Development might skip metrics; production might skip verbose logging.
Testable in Isolation — Each decorator can be tested independently with a mock delegate. The TTLCache tests don't need real metrics.

Interface-Defined Extension Points

Interfaces allow you to define extension points—places where the system explicitly invites new behavior to be plugged in. This turns modification requests into addition requests.

Example: An Extensible Validation System

ValidationExtensionPoints.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
/**
 * Extension point: implement this interface to add custom validation rules.
 */
public interface OrderValidator {
    /**
     * Validates an order before processing.
     * 
     * @param order The order to validate
     * @return ValidationResult containing any errors or warnings
     */
    ValidationResult validate(Order order);
    
    /**
     * Indicates the priority of this validator.
     * Lower values run first.
     */
    default int priority() {
        return 100; // Default priority
    }
}
 
// Core validators - shipped with the system
public class InventoryValidator implements OrderValidator {
    public ValidationResult validate(Order order) {
        for (OrderItem item : order.getItems()) {
            int available = inventory.getAvailable(item.getProductId());
            if (available < item.getQuantity()) {
                return ValidationResult.error(
                    "Insufficient inventory for " + item.getProductId()
                );
            }
        }
        return ValidationResult.valid();
    }
    
    public int priority() { return 10; } // Run early
}
 
public class PaymentValidator implements OrderValidator {
    public ValidationResult validate(Order order) {
        if (!paymentService.canCharge(order.getPaymentMethod())) {
            return ValidationResult.error("Payment method declined");
        }
        return ValidationResult.valid();
    }
    
    public int priority() { return 50; }
}
 
// Custom validators - added by specific business units
public class FraudDetectionValidator implements OrderValidator {
    public ValidationResult validate(Order order) {
        RiskScore risk = fraudService.assessRisk(order);
        if (risk.isHighRisk()) {
            return ValidationResult.error("Order flagged for fraud review");
        }
        if (risk.isMediumRisk()) {
            return ValidationResult.warning("Order requires manual approval");
        }
        return ValidationResult.valid();
    }
    
    public int priority() { return 5; } // Run first
}
 
public class ExportComplianceValidator implements OrderValidator {
    public ValidationResult validate(Order order) {
        if (requiresExportLicense(order) && !hasExportLicense(order)) {
            return ValidationResult.error("Export license required");
        }
        return ValidationResult.valid();
    }
}

The validation engine uses all registered validators:

ValidationEngine.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
public class OrderValidationEngine {
    private final List<OrderValidator> validators;
    
    // Validators are injected - the engine doesn't know concrete types
    public OrderValidationEngine(List<OrderValidator> validators) {
        // Sort by priority
        this.validators = validators.stream()
            .sorted(Comparator.comparingInt(OrderValidator::priority))
            .collect(toList());
    }
    
    public ValidationResult validateOrder(Order order) {
        List<String> errors = new ArrayList<>();
        List<String> warnings = new ArrayList<>();
        
        for (OrderValidator validator : validators) {
            ValidationResult result = validator.validate(order);
            
            if (result.hasErrors()) {
                errors.addAll(result.getErrors());
                if (shouldStopOnError()) {
                    break; // Fail fast
                }
            }
            warnings.addAll(result.getWarnings());
        }
        
        return new ValidationResult(errors, warnings);
    }
}
 
// Registration via framework (Spring example):
@Configuration
public class ValidationConfig {
    @Bean
    public OrderValidationEngine engine(List<OrderValidator> validators) {
        // All @Component classes implementing OrderValidator are auto-discovered
        return new OrderValidationEngine(validators);
    }
}
 
// Adding new validation is just adding a new class:
@Component
public class LoyaltyTierValidator implements OrderValidator {
    // Automatically included in validation without changing any existing code
}

Plugin Architecture

Flexibility Without Prediction

A common objection to interface-based design is: "How can I create the right interface if I don't know what implementations I'll need?"

The answer is that you don't need to predict specific implementations—you need to identify natural boundaries where variation is likely or valuable.

Reliable boundaries for abstraction:

Where to Introduce Interfaces

•External dependencies — Database, file storage, network services, third-party APIs. These almost always have alternative implementations (testing, vendor changes, migration).
•Cross-cutting concerns — Logging, metrics, authentication, caching. Different environments and contexts need different implementations.
•Behavioral policies — Retry logic, timeout handling, circuit breaking. Business requirements dictate different policies.
•Domain strategies — Pricing calculations, discount rules, shipping estimation. Business logic evolves frequently.
•Output channels — Email, SMS, push notifications, webhooks. The set of channels expands over time.
•Input sources — REST APIs, GraphQL, message queues, file imports. Systems acquire new integration points.

Designing interfaces at these boundaries follows a pattern:

Identify the capability — What action does the consuming code need? ("store a document," "send a notification," "compute shipping cost")
Define the contract — What inputs are required? What outputs are expected? What errors can occur?
Keep it minimal — Include only what consumers need. Avoid exposing implementation details.
Name it by purpose — DocumentStorage, not S3Wrapper. NotificationChannel, not TwilioService.

BoundaryInterface.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// Good: named by capability, minimal surface
public interface ShippingCalculator {
    ShippingQuote calculateShipping(
        Address origin,
        Address destination,
        List<Package> packages
    );
}
 
// The interface doesn't expose:
// - Which carrier is used
// - API authentication details
// - Rate negotiation logic
// - Caching strategies
 
// Any of these implementations work:
public class UPSShippingCalculator implements ShippingCalculator { ... }
public class FedExShippingCalculator implements ShippingCalculator { ... }
public class MultiCarrierCalculator implements ShippingCalculator { ... }
public class MockShippingCalculator implements ShippingCalculator { ... }

You Don't Need to Be Right on the First Try

Interface Evolution Strategies

Interfaces provide flexibility, but they themselves must sometimes evolve. How do you add capabilities to an interface without breaking existing implementations?

Strategy 1: Default Methods (Java 8+, C# 8+)

Modern languages allow interfaces to include default implementations:

DefaultMethods.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
public interface MessageQueue {
    // Original methods - must be implemented
    void send(Message message);
    Message receive();
    
    // New method with default implementation
    // Existing implementations continue working
    default void sendBatch(List<Message> messages) {
        for (Message message : messages) {
            send(message);
        }
    }
    
    // New method with sensible default
    default int getPendingCount() {
        return -1; // Unknown
    }
}
 
// Existing implementations still work - they inherit defaults
public class RabbitMQQueue implements MessageQueue {
    public void send(Message message) { ... }
    public Message receive() { ... }
    // sendBatch() and getPendingCount() are inherited
}
 
// New implementations can override for better behavior
public class KafkaQueue implements MessageQueue {
    public void send(Message message) { ... }
    public Message receive() { ... }
    
    @Override
    public void sendBatch(List<Message> messages) {
        // Kafka-optimized batch sending
        producer.send(messages);
    }
    
    @Override
    public int getPendingCount() {
        return consumer.lag();
    }
}

Strategy 2: Interface Segregation

Instead of growing a single interface, split capabilities into focused interfaces:

InterfaceSegregation.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
// Original interface
public interface MessageQueue {
    void send(Message message);
    Message receive();
}
 
// Additional capability as separate interface
public interface BatchMessageQueue extends MessageQueue {
    void sendBatch(List<Message> messages);
}
 
// Another capability
public interface ObservableQueue extends MessageQueue {
    int getPendingCount();
    void addListener(QueueListener listener);
}
 
// Implementations declare which capabilities they support
public class KafkaQueue implements BatchMessageQueue, ObservableQueue {
    // Supports all capabilities
}
 
public class SimpleQueue implements MessageQueue {
    // Supports only basic operations
}
 
// Consumers depend only on what they need
public class BasicProcessor {
    private final MessageQueue queue;  // Only needs basic ops
}
 
public class BatchProcessor {
    private final BatchMessageQueue queue;  // Needs batch capability
}

Strategy 3: Versioned Interfaces

For major changes, create new versions while maintaining backward compatibility:

VersionedInterfaces.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
// Original interface - still supported
public interface PaymentProcessor {
    PaymentResult process(PaymentRequest request);
}
 
// New version with enhanced capabilities
public interface PaymentProcessorV2 extends PaymentProcessor {
    PaymentResult processWithMetadata(
        PaymentRequest request,
        PaymentMetadata metadata
    );
    
    boolean supports3DSecure();
    
    PaymentResult process3DSecure(
        PaymentRequest request,
        ThreeDSecureData secureData
    );
}
 
// Adapter for legacy implementations
public class PaymentProcessorV2Adapter implements PaymentProcessorV2 {
    private final PaymentProcessor legacy;
    
    @Override
    public PaymentResult process(PaymentRequest request) {
        return legacy.process(request);
    }
    
    @Override
    public PaymentResult processWithMetadata(
            PaymentRequest request, PaymentMetadata metadata) {
        // Metadata ignored - legacy doesn't support it
        log.warn("Metadata ignored by legacy processor");
        return legacy.process(request);
    }
    
    @Override
    public boolean supports3DSecure() {
        return false;
    }
    
    @Override
    public PaymentResult process3DSecure(
            PaymentRequest request, ThreeDSecureData secureData) {
        throw new UnsupportedOperationException("Legacy processor");
    }
}

Breaking Changes Are Expensive

Practical Guidelines

Based on the patterns we've explored, here are practical guidelines for leveraging interfaces effectively:

Interface Design Best Practices
Guideline	Rationale	Example
Name interfaces by capability, not implementation	Names should survive implementation changes	`DocumentStorage`, not `S3DocumentStorage`
Keep interfaces small and focused	Smaller interfaces are easier to implement and compose	Split `UserRepository` from `UserQueryService`
Define clear contracts with documentation	Implementations need unambiguous requirements	Document exceptions, null handling, threading
Include only what consumers need	Extra methods become implementation burdens	Don't add `getConnectionPool()` to `Database`
Prefer composition over large interfaces	Composed small interfaces are more flexible	`interface Pageable`, `interface Sortable`
Add new methods with default implementations	Preserves backward compatibility	`default void close() { }`

Common patterns for specific scenarios:

•Need to switch implementations at runtime? — Use Strategy pattern with interface-typed field
•Need to add behavior without modification? — Use Decorator pattern wrapping the interface
•Need to combine multiple implementations? — Use Composite pattern with collection of interface instances
•Need gradual rollout of new implementation? — Use feature toggle wrapping interface selection
•Need to support optional capabilities? — Extend base interface or use interface segregation
•Need graceful degradation? — Chain implementations with fallback logic

Summary and Key Takeaways

Key Takeaways

•Substitution is the core flexibility — Interfaces allow replacing one implementation with another without changing consuming code. This enables environment-specific behavior, vendor switching, and testing.
•Runtime flexibility patterns abound — Strategy selection, feature toggles, and composite behaviors are all enabled by programming to interfaces rather than implementations.
•Decoration adds behavior without modification — The Decorator pattern stacks capabilities (metrics, logging, caching, retry) around implementations without changing them.
•Interfaces define extension points — Plugin architectures and extensible systems are built by defining interfaces that extensions implement.
•You don't need to predict—just identify boundaries — External dependencies, cross-cutting concerns, and domain policies are natural abstraction points.
•Interfaces can evolve safely — Default methods, interface segregation, and versioning allow adding capabilities without breaking existing code.
•Small, focused interfaces compose better — Multiple small interfaces are more flexible than one large interface.

What's next:

Page Complete

2 / 4