System Design (LLD)Validating the Design

Validating the Design

LevelIntermediate

Duration60 mins

TopicValidating the Design

3 / 4

Extensibility Validation

The Inevitable Reality: Requirements Will Change

No matter how thoroughly you gather requirements, no matter how clearly stakeholders articulate their needs, one truth is absolute: requirements will change. Markets shift, user feedback arrives, competitive pressures emerge, and regulations evolve. A design that cannot accommodate change is not a finished product—it's a ticking time bomb.

Extensibility validation ensures that your design is not merely correct today, but prepared for the changes that tomorrow will inevitably bring. This page establishes a rigorous framework for assessing and improving your design's adaptability before implementation begins.

What You Will Master

By the end of this page, you will understand how to identify anticipated change scenarios, evaluate design flexibility through concrete analysis techniques, recognize extension point patterns, and validate that your design's architecture supports evolution without architectural surgery.

Understanding Extensibility

Extensibility is the capacity of a software design to accommodate new requirements, features, or behaviors with minimal modification to existing code. It is not the same as flexibility, generality, or over-engineering. Extensibility is strategic—it targets specific, anticipated directions of change.

The Three Dimensions of Extensibility:

Extensibility Dimensions

•Horizontal Extensibility — The ability to add new variants of existing concepts. Examples: new payment types, new report formats, new notification channels. This is the most common form of extensibility.
•Vertical Extensibility — The ability to add new layers or stages to existing processes. Examples: adding validation steps, inserting middleware, extending processing pipelines.
•Cross-Cutting Extensibility — The ability to add concerns that span multiple components. Examples: adding logging, caching, auditing, or security checks across the system.

The Cost-Benefit Balance:

Extensibility is not free. Every extension point adds complexity:

Interfaces require more thought than direct implementations
Plugin architectures require registration mechanisms
Event-driven designs require event infrastructure

The goal is not maximum extensibility, but strategic extensibility—flexibility where change is anticipated, simplicity where it is not. Validating extensibility means confirming that extension points exist where needed and complexity is not added where it isn't.

The YAGNI Tension

YAGNI (You Aren't Gonna Need It) cautions against building for imaginary requirements. But YAGNI applies to specific features, not architectural flexibility. A design that cannot evolve violates a different principle: invest in the obvious, prepare for the probable, ignore the improbable.

Identifying Anticipated Change Scenarios

Effective extensibility validation begins with explicitly identifying what changes are likely. This is not speculation—it's informed analysis based on domain knowledge, stakeholder input, and industry patterns.

Sources of Change Intelligence:

Change Scenario Sources

•Stakeholder Roadmap: What features are planned but deferred? What capabilities were discussed but deemed out of scope for v1?
•Domain Analysis: What variations exist in the problem domain? If supporting one payment provider, it's likely more will follow. If one report format exists, more are probable.
•Historical Patterns: In similar systems, what changed over time? CRM systems always need new integration points. E-commerce systems always need new payment methods.
•Regulatory Environment: What regulations might emerge? GDPR-style privacy requirements, accessibility mandates, industry-specific compliance.
•Competitive Pressure: What features do competitors offer that stakeholders might request? What market trends might drive new requirements?
•Technical Evolution: What infrastructure might change? Cloud providers, database systems, frameworks, and protocols evolve continuously.

Documenting Change Scenarios:

For each identified change scenario, document:

Description: What is the change?
Probability: How likely is this change? (High/Medium/Low)
Timeline: When might this change be needed? (Near-term/Mid-term/Long-term)
Impact: What parts of the system would be affected?
Design Implications: What extension points or abstractions would support this change?

Example Change Scenario Documentation
Scenario	Probability	Timeline	Affected Areas	Design Response
Add cryptocurrency payment	High	6-12 months	Payment processing, receipts	Payment strategy interface, polymorphic processors
Support multi-language content	Medium	12-18 months	UI, notifications, reports	Content abstraction with locale awareness
Real-time inventory sync	High	3-6 months	Inventory, orders, caching	Event-driven inventory with observer pattern
White-label branding	Low	18+ months	UI, email templates, PDF generation	Theme/brand configuration injection
GDPR-style data export	Medium	6-12 months	All data stores, user management	Data export interface per entity type

The Change Impact Analysis Technique

Change Impact Analysis is a systematic technique for evaluating how well a design accommodates anticipated changes. For each change scenario, trace through the design and count the modifications required.

The Impact Scoring Framework:

Change Impact Scoring
Score	Description	Example	Design Quality Indicator
0 - Configuration Only	Change requires only configuration, no code changes	Toggle a feature flag, adjust a setting	Excellent - design anticipated this change perfectly
1 - Single Addition	Change requires adding one new class/component	Add new PaymentStrategy implementation	Very Good - proper abstraction exists
2-3 - Localized Changes	Change affects 2-3 related components	Add new entity with repository and service	Good - changes are cohesive and contained
4-6 - Cross-Cutting Impact	Change affects multiple unrelated components	Adding auditing across all services	Fair - missing abstraction for this concern
7+ - Architectural Surgery	Change requires restructuring core components	Changing from sync to async processing model	Poor - fundamental architecture doesn't support change

Performing Change Impact Analysis:

Select a Change Scenario: Choose a high-probability anticipated change from your documented scenarios.
Trace the Change Path: Walk through the design, identifying every class, interface, and component that would need modification or addition.
Categorize Modifications:
- New Code: Classes or methods that need to be added
- Modified Code: Existing code that needs changes
- Configuration: Settings or registration that needs updating
Calculate the Impact Score: Count the number of existing files that require modification (new files don't count against extensibility).
Evaluate Against Threshold: High-probability changes should score 0-2. Medium-probability changes should score 0-4. Any change scoring 7+ indicates an extensibility problem.

change-impact-example.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// Change Scenario: Add new "BankTransfer" payment method
 
// ✅ Well-designed system: Impact Score = 1 (Single Addition)
// Files to CREATE (don't count against score):
// - BankTransferPaymentStrategy.ts (new)
// - BankTransferPaymentStrategyTest.ts (new)
 
// Files to MODIFY:
// - PaymentStrategyRegistry.ts (add registration) ← 1 modification
 
// The design anticipated this type of extension
 
// ❌ Poorly-designed system: Impact Score = 8 (Architectural Surgery)
// Files to MODIFY:
// - OrderService.ts (add bank transfer handling)
// - PaymentController.ts (add bank transfer endpoint)
// - PaymentRepository.ts (add bank transfer tables)
// - ReceiptGenerator.ts (add bank transfer receipt format)
// - RefundService.ts (add bank transfer refund logic)
// - PaymentValidator.ts (add bank transfer validation)
// - ReportGenerator.ts (add bank transfer reporting)
// - EmailService.ts (add bank transfer confirmation template)
 
// The design has no abstraction for payment types - 
// each type is hardcoded throughout the system

The Shotgun Surgery Smell

If a single logical change requires modifications scattered across many classes, you've identified 'shotgun surgery'—a design smell indicating missing abstractions. The cure is to extract the commonality into an abstraction that localizes future changes.

Extension Point Patterns

Extension points are well-defined locations in a design where new behavior can be added without modifying existing code. During extensibility validation, verify that appropriate extension point patterns are used where anticipated change exists.

Common Extension Point Patterns:

Strategy-Based Extension

•Pattern: Define an interface for a family of algorithms, implement each variant as a separate class
•Use When: Multiple approaches to the same task (payment processing, sorting, validation)
•Extension Mechanism: Add new strategy class, register with selector
•Validation Check: Is there an interface? Are strategies selected through injection or registry, not if-else chains?

strategy-extension-point.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// Strategy-Based Extension Point
 
interface PricingStrategy {
    calculatePrice(order: Order): Money;
    applicableTo(customer: Customer): boolean;
}
 
class PricingEngine {
    constructor(private strategies: PricingStrategy[]) {}
    
    getPrice(order: Order, customer: Customer): Money {
        const strategy = this.strategies.find(s => s.applicableTo(customer));
        return strategy?.calculatePrice(order) ?? this.defaultPrice(order);
    }
}
 
// Extension: Add new pricing strategy without modifying PricingEngine
class EnterpriseVolumeDiscount implements PricingStrategy {
    applicableTo(customer: Customer): boolean {
        return customer.tier === "enterprise" && customer.annualVolume > 100000;
    }
    
    calculatePrice(order: Order): Money {
        return order.subtotal.multiply(0.75); // 25% discount
    }
}

Observer/Event-Based Extension

•Pattern: Core logic emits events; handlers subscribe to react to events
•Use When: Multiple reactions to the same trigger (order placed → update inventory, send email, record analytics)
•Extension Mechanism: Add new event handler, subscribe to relevant events
•Validation Check: Are significant state changes emitting events? Can new handlers be added without core modification?

event-extension-point.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
// Event-Based Extension Point
 
interface DomainEvent {
    readonly occurredAt: Date;
    readonly aggregateId: string;
}
 
class OrderPlaced implements DomainEvent {
    constructor(
        readonly occurredAt: Date,
        readonly aggregateId: string,
        readonly order: Order
    ) {}
}
 
class OrderService {
    constructor(private eventPublisher: EventPublisher) {}
    
    placeOrder(order: Order): void {
        // Core logic
        this.validateOrder(order);
        this.reserveInventory(order);
        
        // Publish event for extensible reactions
        this.eventPublisher.publish(
            new OrderPlaced(new Date(), order.id, order)
        );
    }
}
 
// Extension: Add new reactions without modifying OrderService
class LoyaltyPointsHandler {
    @SubscribeTo(OrderPlaced)
    handle(event: OrderPlaced): void {
        this.loyaltyService.awardPoints(event.order.customerId, event.order.total);
    }
}
 
class FraudDetectionHandler {
    @SubscribeTo(OrderPlaced)
    handle(event: OrderPlaced): void {
        this.fraudDetector.checkOrder(event.order);
    }
}

Pipeline/Chain Extension

•Pattern: Processing flows through a chain of handlers, each can modify or react
•Use When: Multi-step processing where steps may be added/removed (validation pipeline, processing middleware, filter chains)
•Extension Mechanism: Add new handler to the chain configuration
•Validation Check: Is the pipeline configurable? Can handlers be inserted without modifying others?

Factory/Registry Extension

•Pattern: Factory creates instances based on configuration; registry maps identifiers to implementations
•Use When: Need to select implementations at runtime based on context (parsers for file types, handlers for message types)
•Extension Mechanism: Register new implementation with factory/registry
•Validation Check: Is creation centralized? Can new variants be registered without modifying existing code?

Extensibility Validation Checklist

Apply this comprehensive checklist during design validation to ensure extensibility is properly addressed:

Anticipated Change Coverage

•Are anticipated change scenarios documented? Has stakeholder input been gathered on likely future requirements?
•For each high-probability change, is there a clear extension point or abstraction that supports it?
•Have change impact analyses been performed? Do high-probability changes score 0-2?
•Are the extension mechanisms documented? Would a new developer understand how to add each type of extension?

Abstraction Quality

•Are abstractions (interfaces, abstract classes) used at identified variation points?
•Do abstractions represent stable concepts unlikely to change, with concrete implementations representing the variable parts?
•Are abstractions minimal? Do they expose only what clients need, hiding implementation details?
•Are abstractions well-named? Do the names describe roles/capabilities rather than implementations?

Extension Pattern Validation

•Are appropriate patterns (Strategy, Observer, Factory, Pipeline) used for identified extension points?
•Can new implementations be added without modifying existing code (proper OCP compliance)?
•Is there a clear registration or configuration mechanism for new extensions?
•Are extension points documented with examples of how to add new behavior?

Configuration and Feature Flags

•Are configurable values externalized? Can behavior be adjusted without code changes?
•Is there a feature flag infrastructure for gradual rollouts and A/B testing?
•Can extensions be enabled/disabled through configuration rather than deployment?
•Is there a clear separation between code changes and configuration changes?

Common Extensibility Failures and Remedies

During extensibility validation, watch for these common failure patterns that undermine design flexibility:

Extensibility Anti-Patterns and Solutions
Anti-Pattern	Symptoms	Impact	Remedy
Hardcoded Type Discrimination	switch/if-else on type field, instanceof checks scattered through code	Every new type requires modifying every switch statement	Introduce polymorphism with strategy or visitor pattern
God Class	One class doing everything, 1000+ lines, dozens of methods	Any change risks breaking unrelated functionality	Extract cohesive responsibilities into focused classes
Premature Concretization	Using concrete classes where interfaces could allow variation	Cannot substitute alternative implementations	Program to interfaces, inject dependencies
Missing Seams	No clear boundaries between components, everything directly coupled	Testing is impossible without infrastructure	Introduce interfaces at component boundaries
Configuration Scatter	Configuration values embedded throughout code	Changing a setting requires hunting through codebase	Centralize configuration with injection
Implicit Dependencies	Components reach out to obtain dependencies (Service Locator, statics)	Cannot easily substitute dependencies for testing or extension	Explicit constructor injection

❌ Hardcoded Type Discrimination:

class NotificationService {
    send(notification: Notification): void {
        switch (notification.type) {
            case "email":
                this.sendEmail(notification);
                break;
            case "sms":
                this.sendSMS(notification);
                break;
            case "push":
                this.sendPush(notification);
                break;
            // Adding Slack requires editing here!
            default:
                throw new Error("Unknown type");
        }
    }
    
    private sendEmail(n: Notification) { }
    private sendSMS(n: Notification) { }
    private sendPush(n: Notification) { }
}

✅ Polymorphic Solution:

interface NotificationChannel {
    supports(notification: Notification): boolean;
    send(notification: Notification): void;
}
 
class NotificationService {
    constructor(
        private channels: NotificationChannel[]
    ) {}
    
    send(notification: Notification): void {
        const channel = this.channels.find(
            c => c.supports(notification)
        );
        if (!channel) {
            throw new Error("No channel for notification");
        }
        channel.send(notification);
    }
}
 
// Extension: Add Slack without modifying service
class SlackChannel implements NotificationChannel {
    supports(n: Notification): boolean {
        return n.type === "slack";
    }
    send(n: Notification): void { /* ... */ }
}

Balancing Extensibility and Simplicity

Extensibility validation must include a sanity check against over-engineering. Not every part of the design needs extension points. The goal is strategic extensibility, not universal flexibility.

The Probability-Driven Approach:

Apply different levels of extensibility investment based on change probability:

Extensibility Investment Levels

•High Probability Changes (>70%): Full extension point treatment. Create interfaces, use appropriate patterns, document extension mechanisms. Example: Adding new payment providers when you already support multiple.
•Medium Probability Changes (30-70%): Lightweight extensibility. Use interfaces but don't build elaborate plugin infrastructure. Ensure the code is structured so that adding the feature later won't require rewriting. Example: Adding new notification channels.
•Low Probability Changes (<30%): Simple, clear code. Don't add abstractions for changes that may never come. If the change does materialize, refactoring clean code is straightforward. Example: Supporting right-to-left languages when all current markets are left-to-right.
•Unknown Changes: Design for maintainability, not specific extensions. Keep code modular, well-tested, and well-documented so that any refactoring needed is manageable.

Signs of Over-Engineering:

Interfaces with only one implementation and no planned variation
Abstract factories for objects that are created once at startup
Plugin architectures for features with two variants
Observer patterns where there's only one subscriber

The Rule of Three:

A useful heuristic: wait until you have three variations before creating an abstraction. The first two cases often reveal that the variation isn't what you thought. By the third, you understand the pattern well enough to create a good abstraction.

However, apply judgment: if the cost of abstraction is low and the probability of variation is high, don't wait artificially.

Page Complete

You now have a comprehensive framework for extensibility validation, including change scenario identification, impact analysis, extension point patterns, and balance against over-engineering. The next page focuses on simplicity checking—ensuring your design achieves its goals without unnecessary complexity.

3 / 4

Loading learning content...

System Design (LLD)Validating the Design

Validating the Design

LevelIntermediate

Duration60 mins

TopicValidating the Design

3 / 4

Extensibility Validation

The Inevitable Reality: Requirements Will Change

What You Will Master

Understanding Extensibility

The Three Dimensions of Extensibility:

Extensibility Dimensions

•Horizontal Extensibility — The ability to add new variants of existing concepts. Examples: new payment types, new report formats, new notification channels. This is the most common form of extensibility.
•Vertical Extensibility — The ability to add new layers or stages to existing processes. Examples: adding validation steps, inserting middleware, extending processing pipelines.
•Cross-Cutting Extensibility — The ability to add concerns that span multiple components. Examples: adding logging, caching, auditing, or security checks across the system.

The Cost-Benefit Balance:

Extensibility is not free. Every extension point adds complexity:

Interfaces require more thought than direct implementations
Plugin architectures require registration mechanisms
Event-driven designs require event infrastructure

The YAGNI Tension

Identifying Anticipated Change Scenarios

Sources of Change Intelligence:

Change Scenario Sources

•Stakeholder Roadmap: What features are planned but deferred? What capabilities were discussed but deemed out of scope for v1?
•Domain Analysis: What variations exist in the problem domain? If supporting one payment provider, it's likely more will follow. If one report format exists, more are probable.
•Historical Patterns: In similar systems, what changed over time? CRM systems always need new integration points. E-commerce systems always need new payment methods.
•Regulatory Environment: What regulations might emerge? GDPR-style privacy requirements, accessibility mandates, industry-specific compliance.
•Competitive Pressure: What features do competitors offer that stakeholders might request? What market trends might drive new requirements?
•Technical Evolution: What infrastructure might change? Cloud providers, database systems, frameworks, and protocols evolve continuously.

Documenting Change Scenarios:

For each identified change scenario, document:

Description: What is the change?
Probability: How likely is this change? (High/Medium/Low)
Timeline: When might this change be needed? (Near-term/Mid-term/Long-term)
Impact: What parts of the system would be affected?
Design Implications: What extension points or abstractions would support this change?

Example Change Scenario Documentation
Scenario	Probability	Timeline	Affected Areas	Design Response
Add cryptocurrency payment	High	6-12 months	Payment processing, receipts	Payment strategy interface, polymorphic processors
Support multi-language content	Medium	12-18 months	UI, notifications, reports	Content abstraction with locale awareness
Real-time inventory sync	High	3-6 months	Inventory, orders, caching	Event-driven inventory with observer pattern
White-label branding	Low	18+ months	UI, email templates, PDF generation	Theme/brand configuration injection
GDPR-style data export	Medium	6-12 months	All data stores, user management	Data export interface per entity type

The Change Impact Analysis Technique

The Impact Scoring Framework:

Change Impact Scoring
Score	Description	Example	Design Quality Indicator
0 - Configuration Only	Change requires only configuration, no code changes	Toggle a feature flag, adjust a setting	Excellent - design anticipated this change perfectly
1 - Single Addition	Change requires adding one new class/component	Add new PaymentStrategy implementation	Very Good - proper abstraction exists
2-3 - Localized Changes	Change affects 2-3 related components	Add new entity with repository and service	Good - changes are cohesive and contained
4-6 - Cross-Cutting Impact	Change affects multiple unrelated components	Adding auditing across all services	Fair - missing abstraction for this concern
7+ - Architectural Surgery	Change requires restructuring core components	Changing from sync to async processing model	Poor - fundamental architecture doesn't support change

Performing Change Impact Analysis:

Select a Change Scenario: Choose a high-probability anticipated change from your documented scenarios.
Trace the Change Path: Walk through the design, identifying every class, interface, and component that would need modification or addition.
Categorize Modifications:
- New Code: Classes or methods that need to be added
- Modified Code: Existing code that needs changes
- Configuration: Settings or registration that needs updating
Calculate the Impact Score: Count the number of existing files that require modification (new files don't count against extensibility).
Evaluate Against Threshold: High-probability changes should score 0-2. Medium-probability changes should score 0-4. Any change scoring 7+ indicates an extensibility problem.

change-impact-example.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// Change Scenario: Add new "BankTransfer" payment method
 
// ✅ Well-designed system: Impact Score = 1 (Single Addition)
// Files to CREATE (don't count against score):
// - BankTransferPaymentStrategy.ts (new)
// - BankTransferPaymentStrategyTest.ts (new)
 
// Files to MODIFY:
// - PaymentStrategyRegistry.ts (add registration) ← 1 modification
 
// The design anticipated this type of extension
 
// ❌ Poorly-designed system: Impact Score = 8 (Architectural Surgery)
// Files to MODIFY:
// - OrderService.ts (add bank transfer handling)
// - PaymentController.ts (add bank transfer endpoint)
// - PaymentRepository.ts (add bank transfer tables)
// - ReceiptGenerator.ts (add bank transfer receipt format)
// - RefundService.ts (add bank transfer refund logic)
// - PaymentValidator.ts (add bank transfer validation)
// - ReportGenerator.ts (add bank transfer reporting)
// - EmailService.ts (add bank transfer confirmation template)
 
// The design has no abstraction for payment types - 
// each type is hardcoded throughout the system

The Shotgun Surgery Smell

Extension Point Patterns

Common Extension Point Patterns:

Strategy-Based Extension

•Pattern: Define an interface for a family of algorithms, implement each variant as a separate class
•Use When: Multiple approaches to the same task (payment processing, sorting, validation)
•Extension Mechanism: Add new strategy class, register with selector
•Validation Check: Is there an interface? Are strategies selected through injection or registry, not if-else chains?

strategy-extension-point.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// Strategy-Based Extension Point
 
interface PricingStrategy {
    calculatePrice(order: Order): Money;
    applicableTo(customer: Customer): boolean;
}
 
class PricingEngine {
    constructor(private strategies: PricingStrategy[]) {}
    
    getPrice(order: Order, customer: Customer): Money {
        const strategy = this.strategies.find(s => s.applicableTo(customer));
        return strategy?.calculatePrice(order) ?? this.defaultPrice(order);
    }
}
 
// Extension: Add new pricing strategy without modifying PricingEngine
class EnterpriseVolumeDiscount implements PricingStrategy {
    applicableTo(customer: Customer): boolean {
        return customer.tier === "enterprise" && customer.annualVolume > 100000;
    }
    
    calculatePrice(order: Order): Money {
        return order.subtotal.multiply(0.75); // 25% discount
    }
}

Observer/Event-Based Extension

•Pattern: Core logic emits events; handlers subscribe to react to events
•Use When: Multiple reactions to the same trigger (order placed → update inventory, send email, record analytics)
•Extension Mechanism: Add new event handler, subscribe to relevant events
•Validation Check: Are significant state changes emitting events? Can new handlers be added without core modification?

event-extension-point.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
// Event-Based Extension Point
 
interface DomainEvent {
    readonly occurredAt: Date;
    readonly aggregateId: string;
}
 
class OrderPlaced implements DomainEvent {
    constructor(
        readonly occurredAt: Date,
        readonly aggregateId: string,
        readonly order: Order
    ) {}
}
 
class OrderService {
    constructor(private eventPublisher: EventPublisher) {}
    
    placeOrder(order: Order): void {
        // Core logic
        this.validateOrder(order);
        this.reserveInventory(order);
        
        // Publish event for extensible reactions
        this.eventPublisher.publish(
            new OrderPlaced(new Date(), order.id, order)
        );
    }
}
 
// Extension: Add new reactions without modifying OrderService
class LoyaltyPointsHandler {
    @SubscribeTo(OrderPlaced)
    handle(event: OrderPlaced): void {
        this.loyaltyService.awardPoints(event.order.customerId, event.order.total);
    }
}
 
class FraudDetectionHandler {
    @SubscribeTo(OrderPlaced)
    handle(event: OrderPlaced): void {
        this.fraudDetector.checkOrder(event.order);
    }
}

Pipeline/Chain Extension

•Pattern: Processing flows through a chain of handlers, each can modify or react
•Use When: Multi-step processing where steps may be added/removed (validation pipeline, processing middleware, filter chains)
•Extension Mechanism: Add new handler to the chain configuration
•Validation Check: Is the pipeline configurable? Can handlers be inserted without modifying others?

Factory/Registry Extension

•Pattern: Factory creates instances based on configuration; registry maps identifiers to implementations
•Use When: Need to select implementations at runtime based on context (parsers for file types, handlers for message types)
•Extension Mechanism: Register new implementation with factory/registry
•Validation Check: Is creation centralized? Can new variants be registered without modifying existing code?

Extensibility Validation Checklist

Apply this comprehensive checklist during design validation to ensure extensibility is properly addressed:

Anticipated Change Coverage

•Are anticipated change scenarios documented? Has stakeholder input been gathered on likely future requirements?
•For each high-probability change, is there a clear extension point or abstraction that supports it?
•Have change impact analyses been performed? Do high-probability changes score 0-2?
•Are the extension mechanisms documented? Would a new developer understand how to add each type of extension?

Abstraction Quality

•Are abstractions (interfaces, abstract classes) used at identified variation points?
•Do abstractions represent stable concepts unlikely to change, with concrete implementations representing the variable parts?
•Are abstractions minimal? Do they expose only what clients need, hiding implementation details?
•Are abstractions well-named? Do the names describe roles/capabilities rather than implementations?

Extension Pattern Validation

•Are appropriate patterns (Strategy, Observer, Factory, Pipeline) used for identified extension points?
•Can new implementations be added without modifying existing code (proper OCP compliance)?
•Is there a clear registration or configuration mechanism for new extensions?
•Are extension points documented with examples of how to add new behavior?

Configuration and Feature Flags

•Are configurable values externalized? Can behavior be adjusted without code changes?
•Is there a feature flag infrastructure for gradual rollouts and A/B testing?
•Can extensions be enabled/disabled through configuration rather than deployment?
•Is there a clear separation between code changes and configuration changes?

Common Extensibility Failures and Remedies

During extensibility validation, watch for these common failure patterns that undermine design flexibility:

Extensibility Anti-Patterns and Solutions
Anti-Pattern	Symptoms	Impact	Remedy
Hardcoded Type Discrimination	switch/if-else on type field, instanceof checks scattered through code	Every new type requires modifying every switch statement	Introduce polymorphism with strategy or visitor pattern
God Class	One class doing everything, 1000+ lines, dozens of methods	Any change risks breaking unrelated functionality	Extract cohesive responsibilities into focused classes
Premature Concretization	Using concrete classes where interfaces could allow variation	Cannot substitute alternative implementations	Program to interfaces, inject dependencies
Missing Seams	No clear boundaries between components, everything directly coupled	Testing is impossible without infrastructure	Introduce interfaces at component boundaries
Configuration Scatter	Configuration values embedded throughout code	Changing a setting requires hunting through codebase	Centralize configuration with injection
Implicit Dependencies	Components reach out to obtain dependencies (Service Locator, statics)	Cannot easily substitute dependencies for testing or extension	Explicit constructor injection

❌ Hardcoded Type Discrimination:

class NotificationService {
    send(notification: Notification): void {
        switch (notification.type) {
            case "email":
                this.sendEmail(notification);
                break;
            case "sms":
                this.sendSMS(notification);
                break;
            case "push":
                this.sendPush(notification);
                break;
            // Adding Slack requires editing here!
            default:
                throw new Error("Unknown type");
        }
    }
    
    private sendEmail(n: Notification) { }
    private sendSMS(n: Notification) { }
    private sendPush(n: Notification) { }
}

✅ Polymorphic Solution:

interface NotificationChannel {
    supports(notification: Notification): boolean;
    send(notification: Notification): void;
}
 
class NotificationService {
    constructor(
        private channels: NotificationChannel[]
    ) {}
    
    send(notification: Notification): void {
        const channel = this.channels.find(
            c => c.supports(notification)
        );
        if (!channel) {
            throw new Error("No channel for notification");
        }
        channel.send(notification);
    }
}
 
// Extension: Add Slack without modifying service
class SlackChannel implements NotificationChannel {
    supports(n: Notification): boolean {
        return n.type === "slack";
    }
    send(n: Notification): void { /* ... */ }
}

Balancing Extensibility and Simplicity

Extensibility validation must include a sanity check against over-engineering. Not every part of the design needs extension points. The goal is strategic extensibility, not universal flexibility.

The Probability-Driven Approach:

Apply different levels of extensibility investment based on change probability:

Extensibility Investment Levels

•High Probability Changes (>70%): Full extension point treatment. Create interfaces, use appropriate patterns, document extension mechanisms. Example: Adding new payment providers when you already support multiple.
•Medium Probability Changes (30-70%): Lightweight extensibility. Use interfaces but don't build elaborate plugin infrastructure. Ensure the code is structured so that adding the feature later won't require rewriting. Example: Adding new notification channels.
•Low Probability Changes (<30%): Simple, clear code. Don't add abstractions for changes that may never come. If the change does materialize, refactoring clean code is straightforward. Example: Supporting right-to-left languages when all current markets are left-to-right.
•Unknown Changes: Design for maintainability, not specific extensions. Keep code modular, well-tested, and well-documented so that any refactoring needed is manageable.

Signs of Over-Engineering:

Interfaces with only one implementation and no planned variation
Abstract factories for objects that are created once at startup
Plugin architectures for features with two variants
Observer patterns where there's only one subscriber

The Rule of Three:

However, apply judgment: if the cost of abstraction is low and the probability of variation is high, don't wait artificially.

Page Complete

3 / 4