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

## The Iterative OCP Cycle
 
### Phase 1: Implement Concretely
Build the simplest solution that solves the current problem.
- No interfaces where you have only one implementation
- No factories where you have only one type
- No strategies where you have only one algorithm
- Direct, obvious code that clearly expresses intent
 
### Phase 2: Observe Change Patterns
Track how the code changes over time.
- What parts of the code change frequently?
- What kinds of changes are requested?
- Where do modifications feel painful?
- What patterns emerge in change requests?
 
### Phase 3: Identify Abstraction Opportunities
When real variation appears, recognize it.
- Second implementation of similar logic? Consider interface.
- Third time changing the same code? Time to abstract.
- Change in one place requires changes elsewhere? Seam needed.
- External pressure (new vendor, new channel)? Boundary abstraction.
 
### Phase 4: Refactor to Extensibility
Add abstraction surgically at identified points.
- Extract interface from existing implementation
- Apply strategy pattern to varying behavior
- Introduce factory when selection logic emerges
- Publish events to decouple new subscribers
 
### Phase 5: Validate and Iterate
Confirm the abstraction provides value.
- Does the extension point get used?
- Is the abstraction at the right level?
- Did it make the recent change easier?
- Are there other points that now seem worth abstracting?
 
### Return to Phase 1
Continue building concrete solutions for new features.
The cycle never ends—it's how healthy codebases evolve.

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

// BEFORE: Concrete dependency
class OrderService {
    private shippingService = new ShippingService();
    
    processOrder(order: Order) {
        const shipping = this.shippingService.calculate(order);
        // ...
    }
}
 
// AFTER: Interface extracted, original implementation preserved
interface ShippingCalculator {
    calculate(order: Order): Money;
}
 
class ShippingService implements ShippingCalculator {
    calculate(order: Order): Money { /* same implementation */ }
}
 
class OrderService {
    constructor(private shippingCalculator: ShippingCalculator) {}
    
    processOrder(order: Order) {
        const shipping = this.shippingCalculator.calculate(order);
        // ...
    }
}
 
// Can now add InternationalShippingService, 
// FreeShippingCalculator, etc.

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

// BEFORE: Conditional on type (OCP violation)
function calculateDiscount(order: Order): Money {
    switch (order.customerType) {
        case 'regular': return order.subtotal.multiply(0.05);
        case 'premium': return order.subtotal.multiply(0.15);
        case 'vip': return order.subtotal.multiply(0.25);
        default: return Money.zero();
    }
}
 
// AFTER: Polymorphic discount strategies
interface DiscountStrategy {
    apply(order: Order): Money;
}
 
class RegularDiscount implements DiscountStrategy {
    apply(order: Order): Money { return order.subtotal.multiply(0.05); }
}
 
class PremiumDiscount implements DiscountStrategy {
    apply(order: Order): Money { return order.subtotal.multiply(0.15); }
}
 
class VIPDiscount implements DiscountStrategy {
    apply(order: Order): Money { return order.subtotal.multiply(0.25); }
}
 
// New customer types = new DiscountStrategy implementations
// No modification to existing code needed

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

// Original abstraction - served well but now limiting
interface PaymentProcessor {
    process(amount: Money): PaymentResult;
}
 
// New requirements: idempotency keys, metadata, async processing
// Option 1: Add new methods to interface (breaks existing implementers)
// Option 2: Create new, better interface
 
// OPTION 2: Extend and migrate
interface PaymentProcessorV2 extends PaymentProcessor {
    processAsync(request: PaymentRequest): Promise<PaymentResult>;
}
 
// Adapter for consumers that need the old interface
class PaymentProcessorV2Adapter implements PaymentProcessor {
    constructor(private v2Processor: PaymentProcessorV2) {}
    
    process(amount: Money): PaymentResult {
        // Synchronous wrapper around async processing
        const request = new PaymentRequest({ amount });
        return runSync(() => this.v2Processor.processAsync(request));
    }
}
 
// Migration path:
// 1. New code uses PaymentProcessorV2 directly
// 2. Old consumers continue using PaymentProcessor
// 3. Gradually migrate old consumers to V2
// 4. When all consumers migrated, remove PaymentProcessor interface
 
// ALTERNATIVELY: Strangler pattern
class PaymentService {
    constructor(
        private legacyProcessor: PaymentProcessor,
        private newProcessor: PaymentProcessorV2,
        private useNewProcessor: (amount: Money) => boolean
    ) {}
    
    process(amount: Money): PaymentResult {
        // Routes to new processor for some cases
        // Eventually all cases go to new processor
        // Then remove legacy completely
        if (this.useNewProcessor(amount)) {
            const request = new PaymentRequest({ amount });
            return await this.newProcessor.processAsync(request);
        }
        return this.legacyProcessor.process(amount);
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

## OCP Code Review Checklist
 
### For New Abstractions
- [ ] Is there observable evidence of variation justifying this abstraction?
- [ ] Do we have 2+ implementations, or a clear second one coming soon?
- [ ] Is the interface minimal? Only methods actually used by clients?
- [ ] Would a simpler approach work for now?
 
### For Changes to Existing Code
- [ ] Did this change reveal an extension point opportunity?
- [ ] Is there a pattern in recent changes suggesting we should abstract?
- [ ] Did the changes fight existing abstractions? If so, why?
- [ ] Are we modifying code that was "supposed" to be closed?
 
### For Removing/Simplifying
- [ ] Is there an abstraction we can remove because it never got used?
- [ ] Can we simplify an over-engineered component?
- [ ] Are there deprecated abstractions we should finally delete?
 
### General
- [ ] Did we add tests that will make future refactoring safe?
- [ ] Is the design simple enough that a new team member could understand quickly?
- [ ] If we're adding complexity, is the justification clear and documented?