System Design (HLD)OCP Violations and Fixes

OCP Violations and Fixes

LevelIntermediate

Duration75 mins

TopicOCP Violations and Fixes

3 / 4

Switch Statements on Type

The Structured Trap

There's something psychologically satisfying about a well-organized switch statement. Each case neatly labeled, each block clearly demarcated, often even sorted alphabetically. Compared to sprawling if-else chains, switch statements feel clean and professional.

This psychological comfort is precisely what makes switch statements so dangerous. They lull developers into a false sense of order while committing the exact same OCP violation as if-else chains. The structure is different; the architectural damage is identical.

The Seductive Organization:

Switch statements appeal to our desire for tidiness. Where if-else feels like a series of desperate checks, switch feels like a categorized lookup table. This perceived organization masks the fundamental problem: you're still dispatching on type through explicit conditional logic, and every new type will require modifying this supposedly-organized code.

What You Will Learn

By the end of this page, you will understand why switch statements on type carry the same OCP violations as if-else chains, recognize the specific contexts where switch-on-type appears, comprehend language-specific switch behaviors that affect OCP compliance, and develop strategies for identifying switch statements that need refactoring versus those that don't.

Switch vs If-Else: Structural Isomorphism

Before analyzing switch-specific issues, let's establish a fundamental truth: switch statements on type are structurally isomorphic to if-else chains. They're not a different pattern—they're the same pattern with different syntax.

The Isomorphism Demonstrated:

Any if-else chain checking a type discriminator can be mechanically translated to switch, and vice versa:

isomorphism.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
// IF-ELSE VERSION
function calculateDiscount(customer: Customer): number {
    if (customer.tier === 'bronze') {
        return 0.05;
    } else if (customer.tier === 'silver') {
        return 0.10;
    } else if (customer.tier === 'gold') {
        return 0.15;
    } else if (customer.tier === 'platinum') {
        return 0.20;
    } else {
        return 0;
    }
}
 
// SWITCH VERSION — identical logic, different syntax
function calculateDiscountSwitch(customer: Customer): number {
    switch (customer.tier) {
        case 'bronze':
            return 0.05;
        case 'silver':
            return 0.10;
        case 'gold':
            return 0.15;
        case 'platinum':
            return 0.20;
        default:
            return 0;
    }
}
 
// Both versions:
// - Require modification to add 'diamond' tier
// - Contain scattered discount logic
// - Violate OCP identically

Why The Isomorphism Matters:

Understanding that switch and if-else are structurally equivalent has important implications:

Same violation, same fix: The refactoring strategies that address if-else chains apply equally to switch statements
Don't be fooled by cosmetics: The cleaner appearance of switch doesn't reduce its maintenance burden
Static analysis applies equally: Tools that detect if-else chains for OCP violations should also flag switch statements
Code reviews should apply identical scrutiny: Accepting switch while rejecting equivalent if-else is inconsistent

The Readability Trap

Many style guides recommend preferring switch over if-else for 'readability.' While switch may be easier to scan visually, readability doesn't address the OCP violation. A readable violation is still a violation. Don't confuse local code clarity with global architectural health.

The Anatomy of Switch-on-Type

Switch statements on type follow predictable patterns across codebases. Understanding these patterns helps you recognize violations quickly.

Pattern 1: Enum-Based Dispatch

The most common form uses enums as the discriminator:

enum-dispatch.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
// Enum-based switch dispatch — extremely common
enum OrderStatus {
    PENDING = 'pending',
    CONFIRMED = 'confirmed',
    SHIPPED = 'shipped',
    DELIVERED = 'delivered',
    CANCELLED = 'cancelled',
}
 
class OrderProcessor {
    processStatusChange(order: Order, newStatus: OrderStatus): void {
        switch (newStatus) {
            case OrderStatus.PENDING:
                this.notifyWarehouse(order);
                this.reserveInventory(order);
                break;
            case OrderStatus.CONFIRMED:
                this.sendConfirmationEmail(order);
                this.chargePayment(order);
                break;
            case OrderStatus.SHIPPED:
                this.generateTrackingNumber(order);
                this.notifyCustomer(order);
                break;
            case OrderStatus.DELIVERED:
                this.requestReview(order);
                this.triggerLoyaltyPoints(order);
                break;
            case OrderStatus.CANCELLED:
                this.refundPayment(order);
                this.restoreInventory(order);
                break;
        }
    }
    
    // Same pattern repeated elsewhere
    getNextActions(status: OrderStatus): Action[] { /* switch */ }
    getStatusColor(status: OrderStatus): string { /* switch */ }
    canTransitionTo(from: OrderStatus, to: OrderStatus): boolean { /* switch */ }
}

Pattern 2: String Type Discrimination

When types are represented as strings (often from JSON or API responses):

string-dispatch.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
// String-based type switching — common with API data
interface APIEvent {
    type: string;
    payload: unknown;
    timestamp: Date;
}
 
class EventHandler {
    handle(event: APIEvent): void {
        switch (event.type) {
            case 'user.created':
                this.handleUserCreated(event.payload as UserPayload);
                break;
            case 'user.updated':
                this.handleUserUpdated(event.payload as UserPayload);
                break;
            case 'order.placed':
                this.handleOrderPlaced(event.payload as OrderPayload);
                break;
            case 'order.shipped':
                this.handleOrderShipped(event.payload as OrderPayload);
                break;
            case 'payment.received':
                this.handlePaymentReceived(event.payload as PaymentPayload);
                break;
            case 'payment.failed':
                this.handlePaymentFailed(event.payload as PaymentPayload);
                break;
            default:
                console.warn(`Unhandled event type: ${event.type}`);
        }
    }
}
 
// Adding a new event type (e.g., 'subscription.renewed'):
// - Modify EventHandler.handle()
// - Add case everywhere event types are switched

Pattern 3: Action/Command Dispatch

Common in Redux reducers and similar state management:

action-dispatch.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
// Redux-style reducer with action type switching
interface Action {
    type: string;
    payload?: any;
}
 
function todoReducer(state: TodoState, action: Action): TodoState {
    switch (action.type) {
        case 'ADD_TODO':
            return {
                ...state,
                todos: [...state.todos, action.payload],
            };
        case 'TOGGLE_TODO':
            return {
                ...state,
                todos: state.todos.map(todo =>
                    todo.id === action.payload.id
                        ? { ...todo, completed: !todo.completed }
                        : todo
                ),
            };
        case 'DELETE_TODO':
            return {
                ...state,
                todos: state.todos.filter(todo => todo.id !== action.payload.id),
            };
        case 'CLEAR_COMPLETED':
            return {
                ...state,
                todos: state.todos.filter(todo => !todo.completed),
            };
        case 'SET_FILTER':
            return {
                ...state,
                filter: action.payload,
            };
        default:
            return state;
    }
}
 
// Every new action type = modify the reducer
// In large apps, single reducers can have 50+ cases

Pattern Recognition

All three patterns share the same underlying structure: examine a discriminator field, branch to type-specific logic. The difference is cosmetic (enum vs string vs action type), but the OCP violation is identical.

Switch-Specific Considerations

While structurally isomorphic to if-else, switch statements have some language-specific behaviors that add unique considerations.

The Fall-Through Problem:

In languages like JavaScript, TypeScript, Java, and C, switch statements 'fall through' by default if you forget the break statement:

fall-through.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
// Fall-through bugs are a switch-specific hazard
function getPermissions(role: UserRole): Permission[] {
    const permissions: Permission[] = [];
    
    switch (role) {
        case 'admin':
            permissions.push(Permission.DELETE_USERS);
            permissions.push(Permission.MODIFY_SETTINGS);
            // BUG: Missing break — falls through!
        case 'moderator':
            permissions.push(Permission.BAN_USERS);
            permissions.push(Permission.DELETE_CONTENT);
            // BUG: Missing break — falls through!
        case 'member':
            permissions.push(Permission.CREATE_CONTENT);
            permissions.push(Permission.COMMENT);
            break;
        default:
            permissions.push(Permission.VIEW_ONLY);
    }
    
    return permissions;
}
 
// An 'admin' now gets 'member' permissions too — possibly intended?
// But if you add 'super-admin' between admin and moderator,
// unexpected fall-through behavior can create security vulnerabilities

Intentional Fall-Through:

Some codebases use intentional fall-through to share logic, which compounds the OCP problem:

intentional-fall-through.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
// Intentional fall-through creates hidden coupling
function getFeatures(subscriptionTier: string): Feature[] {
    const features: Feature[] = [];
    
    switch (subscriptionTier) {
        case 'enterprise':
            features.push(Feature.SSO);
            features.push(Feature.AUDIT_LOGS);
            features.push(Feature.DEDICATED_SUPPORT);
            // Intentional fall-through
        case 'professional':
            features.push(Feature.ADVANCED_ANALYTICS);
            features.push(Feature.API_ACCESS);
            features.push(Feature.PRIORITY_SUPPORT);
            // Intentional fall-through
        case 'starter':
            features.push(Feature.BASIC_ANALYTICS);
            features.push(Feature.EMAIL_SUPPORT);
            features.push(Feature.CORE_FEATURES);
            break;
        default:
            features.push(Feature.TRIAL_FEATURES);
    }
    
    return features;
}
 
// Adding a 'team' tier between 'professional' and 'starter':
// - Must understand the fall-through chain
// - Must insert in exactly the right position
// - Risk of breaking existing tier features

TypeScript Exhaustiveness Checking:

TypeScript can provide compile-time exhaustiveness checks for switch statements on discriminated unions, which is an improvement over raw JavaScript:

exhaustiveness.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
// TypeScript exhaustiveness checking
type Shape = 
    | { kind: 'circle'; radius: number }
    | { kind: 'rectangle'; width: number; height: number }
    | { kind: 'triangle'; base: number; height: number };
 
function getArea(shape: Shape): number {
    switch (shape.kind) {
        case 'circle':
            return Math.PI * shape.radius ** 2;
        case 'rectangle':
            return shape.width * shape.height;
        case 'triangle':
            return 0.5 * shape.base * shape.height;
        default:
            // Exhaustiveness check — ensures all cases handled
            const _exhaustive: never = shape;
            throw new Error(`Unhandled shape: ${_exhaustive}`);
    }
}
 
// Adding | { kind: 'pentagon'; side: number } to Shape:
// TypeScript will error — 'pentagon' not handled in switch
// This is BETTER (compile-time safety) but still an OCP violation
// (you still must modify getArea to handle pentagon)

Exhaustiveness Is Damage Control

TypeScript's exhaustiveness checking doesn't eliminate the OCP violation—it makes the violation safer by ensuring you don't forget to modify all switch statements. It's a safety net for an architectural flaw, not a solution to the flaw itself.

The Proliferation Effect

One of the most damaging aspects of switch-on-type is how it proliferates throughout a codebase. A single type discriminator tends to spawn switch statements in multiple locations.

The Proliferation Pattern:

Consider a document management system with different document types:

proliferation.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
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
enum DocumentType {
    PDF = 'pdf',
    WORD = 'word',
    EXCEL = 'excel',
    POWERPOINT = 'powerpoint',
    IMAGE = 'image',
}
 
// Switch #1: Rendering
class DocumentRenderer {
    render(doc: Document): HTMLElement {
        switch (doc.type) {
            case DocumentType.PDF: return this.renderPDF(doc);
            case DocumentType.WORD: return this.renderWord(doc);
            case DocumentType.EXCEL: return this.renderExcel(doc);
            case DocumentType.POWERPOINT: return this.renderPowerPoint(doc);
            case DocumentType.IMAGE: return this.renderImage(doc);
        }
    }
}
 
// Switch #2: Thumbnails
class ThumbnailGenerator {
    generate(doc: Document): ImageBuffer {
        switch (doc.type) {
            case DocumentType.PDF: return this.pdfThumbnail(doc);
            case DocumentType.WORD: return this.wordThumbnail(doc);
            case DocumentType.EXCEL: return this.excelThumbnail(doc);
            case DocumentType.POWERPOINT: return this.pptThumbnail(doc);
            case DocumentType.IMAGE: return this.imageThumbnail(doc);
        }
    }
}
 
// Switch #3: Search indexing
class SearchIndexer {
    extractText(doc: Document): string {
        switch (doc.type) {
            case DocumentType.PDF: return this.extractPDFText(doc);
            case DocumentType.WORD: return this.extractWordText(doc);
            case DocumentType.EXCEL: return this.extractExcelText(doc);
            case DocumentType.POWERPOINT: return this.extractPPTText(doc);
            case DocumentType.IMAGE: return this.ocrImage(doc);
        }
    }
}
 
// Switch #4: Export
class DocumentExporter {
    export(doc: Document, format: ExportFormat): Buffer {
        switch (doc.type) {
            case DocumentType.PDF: return this.exportPDF(doc, format);
            case DocumentType.WORD: return this.exportWord(doc, format);
            case DocumentType.EXCEL: return this.exportExcel(doc, format);
            case DocumentType.POWERPOINT: return this.exportPPT(doc, format);
            case DocumentType.IMAGE: return this.exportImage(doc, format);
        }
    }
}
 
// Switch #5, #6, #7... : Validation, Preview, Sharing, Versioning, etc.

The Maintenance Cascade:

Now imagine adding DocumentType.VIDEO to support video files. The modification checklist becomes enormous:

Changes Required for New Document Type

•DocumentRenderer: Add case DocumentType.VIDEO: return this.renderVideo(doc);
•ThumbnailGenerator: Add video thumbnail extraction logic
•SearchIndexer: Add video transcription/text extraction
•DocumentExporter: Add video export capabilities
•ValidationService: Add video validation rules
•PreviewService: Add video preview generation
•SharingService: Add video-specific sharing logic
•StorageService: Add video storage optimization
•AnalyticsService: Add video viewing analytics
•And every other service that switches on DocumentType...

Quantifying the Problem:

In a real codebase with 10 document types and 15 services that switch on document type, you have 150 pieces of type-specific logic. Adding document type 11 requires modifying 15 files and adding 15 new case blocks. Adding service 16 requires adding 10 new case entries.

With proper polymorphism, adding document type 11 means creating 1 new class that implements the document interface. Adding service 16 means calling the polymorphic method like all other services.

Modification Burden: Switch vs Polymorphism
Action	Switch-Based (10 types, 15 services)	Polymorphic
Add new type	Modify 15 files, 15 new cases	Create 1 new class
Add new service	Add 10 cases to new service	Call polymorphic method
Modify type behavior	Find all 15 locations	Modify 1 class
Remove type	Remove 15 cases (if you find them all)	Delete 1 class

The Hidden Switches

The worst part of proliferation is hidden switches. Not every switch is obvious. Some are buried in utility functions, helper classes, or shared libraries. When adding a new type, developers often miss these hidden locations—leading to runtime errors in production when an 'unhandled' type appears.

Switch in State Management

Switch statements are particularly prevalent in state management patterns like Redux, Vuex, and similar architectures. These patterns deserve special attention because they've normalized switch-on-type as 'the right way' to handle state.

The Redux Pattern:

Redux popularized the 'reducer + switch' pattern:

redux-reducer.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
45
46
47
48
49
50
51
52
// Standard Redux reducer pattern
interface AppState {
    users: User[];
    loading: boolean;
    error: string | null;
}
 
type UserAction =
    | { type: 'USERS_FETCH_START' }
    | { type: 'USERS_FETCH_SUCCESS'; payload: User[] }
    | { type: 'USERS_FETCH_ERROR'; payload: string }
    | { type: 'USER_ADD'; payload: User }
    | { type: 'USER_UPDATE'; payload: { id: string; updates: Partial<User> } }
    | { type: 'USER_DELETE'; payload: string };
 
function userReducer(state: AppState = initialState, action: UserAction): AppState {
    switch (action.type) {
        case 'USERS_FETCH_START':
            return { ...state, loading: true, error: null };
            
        case 'USERS_FETCH_SUCCESS':
            return { ...state, loading: false, users: action.payload };
            
        case 'USERS_FETCH_ERROR':
            return { ...state, loading: false, error: action.payload };
            
        case 'USER_ADD':
            return { ...state, users: [...state.users, action.payload] };
            
        case 'USER_UPDATE':
            return {
                ...state,
                users: state.users.map(user =>
                    user.id === action.payload.id
                        ? { ...user, ...action.payload.updates }
                        : user
                ),
            };
            
        case 'USER_DELETE':
            return {
                ...state,
                users: state.users.filter(user => user.id !== action.payload),
            };
            
        default:
            return state;
    }
}
 
// In large applications, reducers can have 30-50+ cases
// Each new feature = new action types = modify reducer

Why Redux Embraced Switch:

It's worth understanding why Redux chose this pattern:

Explicit over implicit: Redux values being able to see all state changes in one place
Time-travel debugging: Actions as plain objects enables recording/replaying
Functional purity: Reducers are pure functions with no polymorphism
Serializable state: No class instances with methods

These are legitimate design goals—but they come with OCP trade-offs.

Modern Alternatives:

Recognizing the maintenance burden, newer patterns have emerged:

modern-alternatives.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
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
// RTK (Redux Toolkit) approach — reduces boilerplate but still switch-like
import { createSlice } from '@reduxjs/toolkit';
 
const usersSlice = createSlice({
    name: 'users',
    initialState,
    reducers: {
        // Each reducer is a separate function — better separation
        addUser: (state, action) => {
            state.users.push(action.payload);
        },
        updateUser: (state, action) => {
            const user = state.users.find(u => u.id === action.payload.id);
            if (user) Object.assign(user, action.payload.updates);
        },
        deleteUser: (state, action) => {
            state.users = state.users.filter(u => u.id !== action.payload);
        },
    },
});
 
// This is BETTER:
// - Adding new action = add new reducer function (still modify file)
// - But mutations are localized
// - Internally still uses switch-like dispatch
 
// ----------------------------------------------------------
 
// Command pattern alternative — true polymorphism
interface Command<TState> {
    execute(state: TState): TState;
}
 
class AddUserCommand implements Command<AppState> {
    constructor(private user: User) {}
    
    execute(state: AppState): AppState {
        return { ...state, users: [...state.users, this.user] };
    }
}
 
class UpdateUserCommand implements Command<AppState> {
    constructor(private id: string, private updates: Partial<User>) {}
    
    execute(state: AppState): AppState {
        return {
            ...state,
            users: state.users.map(user =>
                user.id === this.id
                    ? { ...user, ...this.updates }
                    : user
            ),
        };
    }
}
 
// Dispatcher is truly OCP-compliant
function dispatch<TState>(state: TState, command: Command<TState>): TState {
    return command.execute(state);  // No switch — polymorphic dispatch
}
 
// Adding new command = new class file — no modification to dispatch

Trade-off Awareness

Redux's switch pattern trades OCP compliance for explicit state management. This might be acceptable for application-level state with limited action types. It becomes problematic when action types proliferate into hundreds, or when you want third-party extension. Choose your trade-offs consciously.

When Switch Is Acceptable

As with if-else chains, not every switch statement is an OCP violation. Some uses are perfectly appropriate and shouldn't be refactored. The key is distinguishing type dispatch (problematic) from value handling (typically fine).

Acceptable Switch Patterns:

Switch Statements That Are Typically OK

•Finite, Closed Sets: Days of week, months, HTTP methods — sets that genuinely won't expand
•Mathematical Cases: Handling positive/negative/zero, quadrants, comparisons
•Parser/Lexer Tokens: Switching on token types in a language with fixed syntax
•Keyboard/Mouse Events: keyCode or button values in fixed hardware constraints
•Protocol Constants: HTTP status code ranges, standard error codes
•Configuration Mapping: Small, fixed mapping tables (not type dispatch)

acceptable-switches.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
45
46
47
48
49
50
51
52
53
// ACCEPTABLE: Finite, stable set (days of week)
function getWeekendStatus(day: DayOfWeek): string {
    switch (day) {
        case DayOfWeek.SATURDAY:
        case DayOfWeek.SUNDAY:
            return 'weekend';
        default:
            return 'weekday';
    }
}
 
// ACCEPTABLE: Mathematical/logical cases
function compareNumbers(a: number, b: number): string {
    switch (Math.sign(a - b)) {
        case 1:
            return 'greater';
        case -1:
            return 'less';
        case 0:
            return 'equal';
    }
}
 
// ACCEPTABLE: HTTP status code ranges (standardized, fixed)
function categorizeHttpStatus(status: number): string {
    switch (true) {
        case status >= 200 && status < 300:
            return 'success';
        case status >= 300 && status < 400:
            return 'redirect';
        case status >= 400 && status < 500:
            return 'client_error';
        case status >= 500:
            return 'server_error';
        default:
            return 'unknown';
    }
}
 
// ACCEPTABLE: Lexer/parser tokens (language syntax is fixed)
function parseToken(token: Token): ASTNode {
    switch (token.type) {
        case TokenType.NUMBER:
            return new NumberLiteral(token.value);
        case TokenType.STRING:
            return new StringLiteral(token.value);
        case TokenType.IDENTIFIER:
            return new Identifier(token.value);
        case TokenType.OPERATOR:
            return new Operator(token.value);
        // Language syntax is designed and fixed
    }
}

The Distinguishing Questions:

When evaluating whether a switch statement is acceptable, ask:

Is this set closed by definition? Days of week are closed. Payment types are open.
Would adding a new case be a design change, not just new functionality? Adding an 8th day of week would be a fundamental change. Adding a 5th payment type is routine.
Does this switch appear in multiple places? One switch on HTTP status ranges is fine. The same switch in 10 different places suggests something should be polymorphic.
Could a third party reasonably want to add a new case? If yes, polymorphism enables this. If the set is defined by standards or physics, switch is fine.

The Extension Likelihood Test

Ask: 'In the next 5 years, what's the probability someone will want to add a new case?' For HTTP status categories: nearly zero. For payment methods: nearly 100%. Design accordingly.

From Switch to Polymorphism

Let's preview the transformation from switch-on-type to polymorphic design. While the detailed refactoring process comes in the next page, understanding the conceptual transformation here builds the mental model.

The Transformation Framework:

Converting switch statements to polymorphism follows a predictable pattern:

Identify the discriminator: What value is being switched on?
Extract an interface: What behavior varies by case?
Create implementations: Each case becomes a class
Remove the switch: Replace with polymorphic method call
Relocate construction: Decide where/how to create appropriate instances

transformation-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
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
// BEFORE: Switch-based discount calculation
enum CustomerTier {
    BRONZE = 'bronze',
    SILVER = 'silver',
    GOLD = 'gold',
    PLATINUM = 'platinum',
}
 
class DiscountService {
    calculateDiscount(tier: CustomerTier, amount: Money): Money {
        switch (tier) {
            case CustomerTier.BRONZE:
                return amount.multiply(0.05);
            case CustomerTier.SILVER:
                return amount.multiply(0.10);
            case CustomerTier.GOLD:
                return amount.multiply(0.15).max(new Money(50));
            case CustomerTier.PLATINUM:
                return amount.multiply(0.20).max(new Money(100));
        }
    }
    
    getPerks(tier: CustomerTier): Perk[] {
        switch (tier) {
            case CustomerTier.BRONZE: return [Perk.NEWSLETTER];
            case CustomerTier.SILVER: return [Perk.NEWSLETTER, Perk.EARLY_ACCESS];
            case CustomerTier.GOLD: return [Perk.NEWSLETTER, Perk.EARLY_ACCESS, Perk.PRIORITY_SUPPORT];
            case CustomerTier.PLATINUM: return [Perk.ALL];
        }
    }
}
 
// ------------------------------------------------------------------
 
// AFTER: Polymorphic design
interface CustomerTier {
    calculateDiscount(amount: Money): Money;
    getPerks(): Perk[];
}
 
class BronzeTier implements CustomerTier {
    calculateDiscount(amount: Money): Money {
        return amount.multiply(0.05);
    }
    getPerks(): Perk[] {
        return [Perk.NEWSLETTER];
    }
}
 
class SilverTier implements CustomerTier {
    calculateDiscount(amount: Money): Money {
        return amount.multiply(0.10);
    }
    getPerks(): Perk[] {
        return [Perk.NEWSLETTER, Perk.EARLY_ACCESS];
    }
}
 
class GoldTier implements CustomerTier {
    calculateDiscount(amount: Money): Money {
        return amount.multiply(0.15).max(new Money(50));
    }
    getPerks(): Perk[] {
        return [Perk.NEWSLETTER, Perk.EARLY_ACCESS, Perk.PRIORITY_SUPPORT];
    }
}
 
class PlatinumTier implements CustomerTier {
    calculateDiscount(amount: Money): Money {
        return amount.multiply(0.20).max(new Money(100));
    }
    getPerks(): Perk[] {
        return [Perk.ALL];
    }
}
 
// Service becomes trivial — NO SWITCH
class DiscountService {
    calculateDiscount(tier: CustomerTier, amount: Money): Money {
        return tier.calculateDiscount(amount);  // Polymorphic call
    }
    
    getPerks(tier: CustomerTier): Perk[] {
        return tier.getPerks();  // Polymorphic call
    }
}
 
// Adding DiamondTier: create new class, no modifications to DiscountService

Where Does the Switch Go?

A common question: 'The switch has to exist somewhere—where does it go?'

The switch moves to the construction layer, which is typically:

Factory method/class: A factory that creates the right tier based on configuration
Dependency injection: Container configuration wires up the right implementations
Database/configuration mapping: Tier stored in database, factory creates instance

The key insight: the switch runs once at construction time, not repeatedly at every use site.

The Factory Pattern

The factory pattern often contains a switch statement that creates the appropriate concrete type. This is acceptable because: (1) it's in one place, not scattered, (2) it converts data to objects once, (3) the rest of the system uses polymorphism. The factory is the last switch standing.

Summary and Key Takeaways

We've thoroughly examined switch statements on type as an OCP violation pattern. Let's consolidate our understanding:

Key Takeaways

•Switch statements are isomorphic to if-else chains — Same OCP violation, different syntax. Don't be fooled by cleaner appearance.
•Switch appears in recognizable patterns — Enum dispatch, string discrimination, action/command handling. Learn to spot these.
•Language features add complexity — Fall-through behavior, exhaustiveness checking, pattern matching. Each requires awareness.
•Switch statements proliferate — One discriminator spawns switches throughout the codebase, creating multiplicative maintenance burden.
•State management patterns normalize switch — Redux/Vuex patterns trade OCP compliance for explicit state handling. Make conscious trade-offs.
•Not all switches are violations — Finite, closed sets (days, HTTP ranges) are acceptable. Open, extensible sets need polymorphism.
•The transformation is mechanical — Extract interface, create implementations, replace switch with polymorphic call, relocate construction.
•The factory contains the last switch — Transform data to objects once; use polymorphism everywhere else.

What's Next:

In the final page of this module, we'll bring everything together with Refactoring to OCP-Compliant Design. You'll learn systematic techniques for transforming if-else chains, instanceof checks, and switch statements into extensible, polymorphic architectures. We'll work through complete before/after examples demonstrating the full refactoring process.

Page Complete

You now understand switch statements on type as OCP violations, can recognize when they're problematic versus acceptable, and have a conceptual framework for transformation. Next: comprehensive refactoring techniques.

3 / 4

Loading learning content...

System Design (HLD)OCP Violations and Fixes

OCP Violations and Fixes

LevelIntermediate

Duration75 mins

TopicOCP Violations and Fixes

3 / 4

Switch Statements on Type

The Structured Trap

The Seductive Organization:

What You Will Learn

Switch vs If-Else: Structural Isomorphism

The Isomorphism Demonstrated:

Any if-else chain checking a type discriminator can be mechanically translated to switch, and vice versa:

isomorphism.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
// IF-ELSE VERSION
function calculateDiscount(customer: Customer): number {
    if (customer.tier === 'bronze') {
        return 0.05;
    } else if (customer.tier === 'silver') {
        return 0.10;
    } else if (customer.tier === 'gold') {
        return 0.15;
    } else if (customer.tier === 'platinum') {
        return 0.20;
    } else {
        return 0;
    }
}
 
// SWITCH VERSION — identical logic, different syntax
function calculateDiscountSwitch(customer: Customer): number {
    switch (customer.tier) {
        case 'bronze':
            return 0.05;
        case 'silver':
            return 0.10;
        case 'gold':
            return 0.15;
        case 'platinum':
            return 0.20;
        default:
            return 0;
    }
}
 
// Both versions:
// - Require modification to add 'diamond' tier
// - Contain scattered discount logic
// - Violate OCP identically

Why The Isomorphism Matters:

Understanding that switch and if-else are structurally equivalent has important implications:

Same violation, same fix: The refactoring strategies that address if-else chains apply equally to switch statements
Don't be fooled by cosmetics: The cleaner appearance of switch doesn't reduce its maintenance burden
Static analysis applies equally: Tools that detect if-else chains for OCP violations should also flag switch statements
Code reviews should apply identical scrutiny: Accepting switch while rejecting equivalent if-else is inconsistent

The Readability Trap

The Anatomy of Switch-on-Type

Switch statements on type follow predictable patterns across codebases. Understanding these patterns helps you recognize violations quickly.

Pattern 1: Enum-Based Dispatch

The most common form uses enums as the discriminator:

enum-dispatch.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
// Enum-based switch dispatch — extremely common
enum OrderStatus {
    PENDING = 'pending',
    CONFIRMED = 'confirmed',
    SHIPPED = 'shipped',
    DELIVERED = 'delivered',
    CANCELLED = 'cancelled',
}
 
class OrderProcessor {
    processStatusChange(order: Order, newStatus: OrderStatus): void {
        switch (newStatus) {
            case OrderStatus.PENDING:
                this.notifyWarehouse(order);
                this.reserveInventory(order);
                break;
            case OrderStatus.CONFIRMED:
                this.sendConfirmationEmail(order);
                this.chargePayment(order);
                break;
            case OrderStatus.SHIPPED:
                this.generateTrackingNumber(order);
                this.notifyCustomer(order);
                break;
            case OrderStatus.DELIVERED:
                this.requestReview(order);
                this.triggerLoyaltyPoints(order);
                break;
            case OrderStatus.CANCELLED:
                this.refundPayment(order);
                this.restoreInventory(order);
                break;
        }
    }
    
    // Same pattern repeated elsewhere
    getNextActions(status: OrderStatus): Action[] { /* switch */ }
    getStatusColor(status: OrderStatus): string { /* switch */ }
    canTransitionTo(from: OrderStatus, to: OrderStatus): boolean { /* switch */ }
}

Pattern 2: String Type Discrimination

When types are represented as strings (often from JSON or API responses):

string-dispatch.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
// String-based type switching — common with API data
interface APIEvent {
    type: string;
    payload: unknown;
    timestamp: Date;
}
 
class EventHandler {
    handle(event: APIEvent): void {
        switch (event.type) {
            case 'user.created':
                this.handleUserCreated(event.payload as UserPayload);
                break;
            case 'user.updated':
                this.handleUserUpdated(event.payload as UserPayload);
                break;
            case 'order.placed':
                this.handleOrderPlaced(event.payload as OrderPayload);
                break;
            case 'order.shipped':
                this.handleOrderShipped(event.payload as OrderPayload);
                break;
            case 'payment.received':
                this.handlePaymentReceived(event.payload as PaymentPayload);
                break;
            case 'payment.failed':
                this.handlePaymentFailed(event.payload as PaymentPayload);
                break;
            default:
                console.warn(`Unhandled event type: ${event.type}`);
        }
    }
}
 
// Adding a new event type (e.g., 'subscription.renewed'):
// - Modify EventHandler.handle()
// - Add case everywhere event types are switched

Pattern 3: Action/Command Dispatch

Common in Redux reducers and similar state management:

action-dispatch.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
// Redux-style reducer with action type switching
interface Action {
    type: string;
    payload?: any;
}
 
function todoReducer(state: TodoState, action: Action): TodoState {
    switch (action.type) {
        case 'ADD_TODO':
            return {
                ...state,
                todos: [...state.todos, action.payload],
            };
        case 'TOGGLE_TODO':
            return {
                ...state,
                todos: state.todos.map(todo =>
                    todo.id === action.payload.id
                        ? { ...todo, completed: !todo.completed }
                        : todo
                ),
            };
        case 'DELETE_TODO':
            return {
                ...state,
                todos: state.todos.filter(todo => todo.id !== action.payload.id),
            };
        case 'CLEAR_COMPLETED':
            return {
                ...state,
                todos: state.todos.filter(todo => !todo.completed),
            };
        case 'SET_FILTER':
            return {
                ...state,
                filter: action.payload,
            };
        default:
            return state;
    }
}
 
// Every new action type = modify the reducer
// In large apps, single reducers can have 50+ cases

Pattern Recognition

Switch-Specific Considerations

While structurally isomorphic to if-else, switch statements have some language-specific behaviors that add unique considerations.

The Fall-Through Problem:

In languages like JavaScript, TypeScript, Java, and C, switch statements 'fall through' by default if you forget the break statement:

fall-through.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
// Fall-through bugs are a switch-specific hazard
function getPermissions(role: UserRole): Permission[] {
    const permissions: Permission[] = [];
    
    switch (role) {
        case 'admin':
            permissions.push(Permission.DELETE_USERS);
            permissions.push(Permission.MODIFY_SETTINGS);
            // BUG: Missing break — falls through!
        case 'moderator':
            permissions.push(Permission.BAN_USERS);
            permissions.push(Permission.DELETE_CONTENT);
            // BUG: Missing break — falls through!
        case 'member':
            permissions.push(Permission.CREATE_CONTENT);
            permissions.push(Permission.COMMENT);
            break;
        default:
            permissions.push(Permission.VIEW_ONLY);
    }
    
    return permissions;
}
 
// An 'admin' now gets 'member' permissions too — possibly intended?
// But if you add 'super-admin' between admin and moderator,
// unexpected fall-through behavior can create security vulnerabilities

Intentional Fall-Through:

Some codebases use intentional fall-through to share logic, which compounds the OCP problem:

intentional-fall-through.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
// Intentional fall-through creates hidden coupling
function getFeatures(subscriptionTier: string): Feature[] {
    const features: Feature[] = [];
    
    switch (subscriptionTier) {
        case 'enterprise':
            features.push(Feature.SSO);
            features.push(Feature.AUDIT_LOGS);
            features.push(Feature.DEDICATED_SUPPORT);
            // Intentional fall-through
        case 'professional':
            features.push(Feature.ADVANCED_ANALYTICS);
            features.push(Feature.API_ACCESS);
            features.push(Feature.PRIORITY_SUPPORT);
            // Intentional fall-through
        case 'starter':
            features.push(Feature.BASIC_ANALYTICS);
            features.push(Feature.EMAIL_SUPPORT);
            features.push(Feature.CORE_FEATURES);
            break;
        default:
            features.push(Feature.TRIAL_FEATURES);
    }
    
    return features;
}
 
// Adding a 'team' tier between 'professional' and 'starter':
// - Must understand the fall-through chain
// - Must insert in exactly the right position
// - Risk of breaking existing tier features

TypeScript Exhaustiveness Checking:

TypeScript can provide compile-time exhaustiveness checks for switch statements on discriminated unions, which is an improvement over raw JavaScript:

exhaustiveness.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
// TypeScript exhaustiveness checking
type Shape = 
    | { kind: 'circle'; radius: number }
    | { kind: 'rectangle'; width: number; height: number }
    | { kind: 'triangle'; base: number; height: number };
 
function getArea(shape: Shape): number {
    switch (shape.kind) {
        case 'circle':
            return Math.PI * shape.radius ** 2;
        case 'rectangle':
            return shape.width * shape.height;
        case 'triangle':
            return 0.5 * shape.base * shape.height;
        default:
            // Exhaustiveness check — ensures all cases handled
            const _exhaustive: never = shape;
            throw new Error(`Unhandled shape: ${_exhaustive}`);
    }
}
 
// Adding | { kind: 'pentagon'; side: number } to Shape:
// TypeScript will error — 'pentagon' not handled in switch
// This is BETTER (compile-time safety) but still an OCP violation
// (you still must modify getArea to handle pentagon)

Exhaustiveness Is Damage Control

The Proliferation Effect

One of the most damaging aspects of switch-on-type is how it proliferates throughout a codebase. A single type discriminator tends to spawn switch statements in multiple locations.

The Proliferation Pattern:

Consider a document management system with different document types:

proliferation.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
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
enum DocumentType {
    PDF = 'pdf',
    WORD = 'word',
    EXCEL = 'excel',
    POWERPOINT = 'powerpoint',
    IMAGE = 'image',
}
 
// Switch #1: Rendering
class DocumentRenderer {
    render(doc: Document): HTMLElement {
        switch (doc.type) {
            case DocumentType.PDF: return this.renderPDF(doc);
            case DocumentType.WORD: return this.renderWord(doc);
            case DocumentType.EXCEL: return this.renderExcel(doc);
            case DocumentType.POWERPOINT: return this.renderPowerPoint(doc);
            case DocumentType.IMAGE: return this.renderImage(doc);
        }
    }
}
 
// Switch #2: Thumbnails
class ThumbnailGenerator {
    generate(doc: Document): ImageBuffer {
        switch (doc.type) {
            case DocumentType.PDF: return this.pdfThumbnail(doc);
            case DocumentType.WORD: return this.wordThumbnail(doc);
            case DocumentType.EXCEL: return this.excelThumbnail(doc);
            case DocumentType.POWERPOINT: return this.pptThumbnail(doc);
            case DocumentType.IMAGE: return this.imageThumbnail(doc);
        }
    }
}
 
// Switch #3: Search indexing
class SearchIndexer {
    extractText(doc: Document): string {
        switch (doc.type) {
            case DocumentType.PDF: return this.extractPDFText(doc);
            case DocumentType.WORD: return this.extractWordText(doc);
            case DocumentType.EXCEL: return this.extractExcelText(doc);
            case DocumentType.POWERPOINT: return this.extractPPTText(doc);
            case DocumentType.IMAGE: return this.ocrImage(doc);
        }
    }
}
 
// Switch #4: Export
class DocumentExporter {
    export(doc: Document, format: ExportFormat): Buffer {
        switch (doc.type) {
            case DocumentType.PDF: return this.exportPDF(doc, format);
            case DocumentType.WORD: return this.exportWord(doc, format);
            case DocumentType.EXCEL: return this.exportExcel(doc, format);
            case DocumentType.POWERPOINT: return this.exportPPT(doc, format);
            case DocumentType.IMAGE: return this.exportImage(doc, format);
        }
    }
}
 
// Switch #5, #6, #7... : Validation, Preview, Sharing, Versioning, etc.

The Maintenance Cascade:

Now imagine adding DocumentType.VIDEO to support video files. The modification checklist becomes enormous:

Changes Required for New Document Type

•DocumentRenderer: Add case DocumentType.VIDEO: return this.renderVideo(doc);
•ThumbnailGenerator: Add video thumbnail extraction logic
•SearchIndexer: Add video transcription/text extraction
•DocumentExporter: Add video export capabilities
•ValidationService: Add video validation rules
•PreviewService: Add video preview generation
•SharingService: Add video-specific sharing logic
•StorageService: Add video storage optimization
•AnalyticsService: Add video viewing analytics
•And every other service that switches on DocumentType...

Quantifying the Problem:

With proper polymorphism, adding document type 11 means creating 1 new class that implements the document interface. Adding service 16 means calling the polymorphic method like all other services.

Modification Burden: Switch vs Polymorphism
Action	Switch-Based (10 types, 15 services)	Polymorphic
Add new type	Modify 15 files, 15 new cases	Create 1 new class
Add new service	Add 10 cases to new service	Call polymorphic method
Modify type behavior	Find all 15 locations	Modify 1 class
Remove type	Remove 15 cases (if you find them all)	Delete 1 class

The Hidden Switches

Switch in State Management

The Redux Pattern:

Redux popularized the 'reducer + switch' pattern:

redux-reducer.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
45
46
47
48
49
50
51
52
// Standard Redux reducer pattern
interface AppState {
    users: User[];
    loading: boolean;
    error: string | null;
}
 
type UserAction =
    | { type: 'USERS_FETCH_START' }
    | { type: 'USERS_FETCH_SUCCESS'; payload: User[] }
    | { type: 'USERS_FETCH_ERROR'; payload: string }
    | { type: 'USER_ADD'; payload: User }
    | { type: 'USER_UPDATE'; payload: { id: string; updates: Partial<User> } }
    | { type: 'USER_DELETE'; payload: string };
 
function userReducer(state: AppState = initialState, action: UserAction): AppState {
    switch (action.type) {
        case 'USERS_FETCH_START':
            return { ...state, loading: true, error: null };
            
        case 'USERS_FETCH_SUCCESS':
            return { ...state, loading: false, users: action.payload };
            
        case 'USERS_FETCH_ERROR':
            return { ...state, loading: false, error: action.payload };
            
        case 'USER_ADD':
            return { ...state, users: [...state.users, action.payload] };
            
        case 'USER_UPDATE':
            return {
                ...state,
                users: state.users.map(user =>
                    user.id === action.payload.id
                        ? { ...user, ...action.payload.updates }
                        : user
                ),
            };
            
        case 'USER_DELETE':
            return {
                ...state,
                users: state.users.filter(user => user.id !== action.payload),
            };
            
        default:
            return state;
    }
}
 
// In large applications, reducers can have 30-50+ cases
// Each new feature = new action types = modify reducer

Why Redux Embraced Switch:

It's worth understanding why Redux chose this pattern:

Explicit over implicit: Redux values being able to see all state changes in one place
Time-travel debugging: Actions as plain objects enables recording/replaying
Functional purity: Reducers are pure functions with no polymorphism
Serializable state: No class instances with methods

These are legitimate design goals—but they come with OCP trade-offs.

Modern Alternatives:

Recognizing the maintenance burden, newer patterns have emerged:

modern-alternatives.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
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
// RTK (Redux Toolkit) approach — reduces boilerplate but still switch-like
import { createSlice } from '@reduxjs/toolkit';
 
const usersSlice = createSlice({
    name: 'users',
    initialState,
    reducers: {
        // Each reducer is a separate function — better separation
        addUser: (state, action) => {
            state.users.push(action.payload);
        },
        updateUser: (state, action) => {
            const user = state.users.find(u => u.id === action.payload.id);
            if (user) Object.assign(user, action.payload.updates);
        },
        deleteUser: (state, action) => {
            state.users = state.users.filter(u => u.id !== action.payload);
        },
    },
});
 
// This is BETTER:
// - Adding new action = add new reducer function (still modify file)
// - But mutations are localized
// - Internally still uses switch-like dispatch
 
// ----------------------------------------------------------
 
// Command pattern alternative — true polymorphism
interface Command<TState> {
    execute(state: TState): TState;
}
 
class AddUserCommand implements Command<AppState> {
    constructor(private user: User) {}
    
    execute(state: AppState): AppState {
        return { ...state, users: [...state.users, this.user] };
    }
}
 
class UpdateUserCommand implements Command<AppState> {
    constructor(private id: string, private updates: Partial<User>) {}
    
    execute(state: AppState): AppState {
        return {
            ...state,
            users: state.users.map(user =>
                user.id === this.id
                    ? { ...user, ...this.updates }
                    : user
            ),
        };
    }
}
 
// Dispatcher is truly OCP-compliant
function dispatch<TState>(state: TState, command: Command<TState>): TState {
    return command.execute(state);  // No switch — polymorphic dispatch
}
 
// Adding new command = new class file — no modification to dispatch

Trade-off Awareness

When Switch Is Acceptable

Acceptable Switch Patterns:

Switch Statements That Are Typically OK

•Finite, Closed Sets: Days of week, months, HTTP methods — sets that genuinely won't expand
•Mathematical Cases: Handling positive/negative/zero, quadrants, comparisons
•Parser/Lexer Tokens: Switching on token types in a language with fixed syntax
•Keyboard/Mouse Events: keyCode or button values in fixed hardware constraints
•Protocol Constants: HTTP status code ranges, standard error codes
•Configuration Mapping: Small, fixed mapping tables (not type dispatch)

acceptable-switches.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
45
46
47
48
49
50
51
52
53
// ACCEPTABLE: Finite, stable set (days of week)
function getWeekendStatus(day: DayOfWeek): string {
    switch (day) {
        case DayOfWeek.SATURDAY:
        case DayOfWeek.SUNDAY:
            return 'weekend';
        default:
            return 'weekday';
    }
}
 
// ACCEPTABLE: Mathematical/logical cases
function compareNumbers(a: number, b: number): string {
    switch (Math.sign(a - b)) {
        case 1:
            return 'greater';
        case -1:
            return 'less';
        case 0:
            return 'equal';
    }
}
 
// ACCEPTABLE: HTTP status code ranges (standardized, fixed)
function categorizeHttpStatus(status: number): string {
    switch (true) {
        case status >= 200 && status < 300:
            return 'success';
        case status >= 300 && status < 400:
            return 'redirect';
        case status >= 400 && status < 500:
            return 'client_error';
        case status >= 500:
            return 'server_error';
        default:
            return 'unknown';
    }
}
 
// ACCEPTABLE: Lexer/parser tokens (language syntax is fixed)
function parseToken(token: Token): ASTNode {
    switch (token.type) {
        case TokenType.NUMBER:
            return new NumberLiteral(token.value);
        case TokenType.STRING:
            return new StringLiteral(token.value);
        case TokenType.IDENTIFIER:
            return new Identifier(token.value);
        case TokenType.OPERATOR:
            return new Operator(token.value);
        // Language syntax is designed and fixed
    }
}

The Distinguishing Questions:

When evaluating whether a switch statement is acceptable, ask:

Is this set closed by definition? Days of week are closed. Payment types are open.
Would adding a new case be a design change, not just new functionality? Adding an 8th day of week would be a fundamental change. Adding a 5th payment type is routine.
Does this switch appear in multiple places? One switch on HTTP status ranges is fine. The same switch in 10 different places suggests something should be polymorphic.
Could a third party reasonably want to add a new case? If yes, polymorphism enables this. If the set is defined by standards or physics, switch is fine.

The Extension Likelihood Test

Ask: 'In the next 5 years, what's the probability someone will want to add a new case?' For HTTP status categories: nearly zero. For payment methods: nearly 100%. Design accordingly.

From Switch to Polymorphism

The Transformation Framework:

Converting switch statements to polymorphism follows a predictable pattern:

Identify the discriminator: What value is being switched on?
Extract an interface: What behavior varies by case?
Create implementations: Each case becomes a class
Remove the switch: Replace with polymorphic method call
Relocate construction: Decide where/how to create appropriate instances

transformation-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
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
// BEFORE: Switch-based discount calculation
enum CustomerTier {
    BRONZE = 'bronze',
    SILVER = 'silver',
    GOLD = 'gold',
    PLATINUM = 'platinum',
}
 
class DiscountService {
    calculateDiscount(tier: CustomerTier, amount: Money): Money {
        switch (tier) {
            case CustomerTier.BRONZE:
                return amount.multiply(0.05);
            case CustomerTier.SILVER:
                return amount.multiply(0.10);
            case CustomerTier.GOLD:
                return amount.multiply(0.15).max(new Money(50));
            case CustomerTier.PLATINUM:
                return amount.multiply(0.20).max(new Money(100));
        }
    }
    
    getPerks(tier: CustomerTier): Perk[] {
        switch (tier) {
            case CustomerTier.BRONZE: return [Perk.NEWSLETTER];
            case CustomerTier.SILVER: return [Perk.NEWSLETTER, Perk.EARLY_ACCESS];
            case CustomerTier.GOLD: return [Perk.NEWSLETTER, Perk.EARLY_ACCESS, Perk.PRIORITY_SUPPORT];
            case CustomerTier.PLATINUM: return [Perk.ALL];
        }
    }
}
 
// ------------------------------------------------------------------
 
// AFTER: Polymorphic design
interface CustomerTier {
    calculateDiscount(amount: Money): Money;
    getPerks(): Perk[];
}
 
class BronzeTier implements CustomerTier {
    calculateDiscount(amount: Money): Money {
        return amount.multiply(0.05);
    }
    getPerks(): Perk[] {
        return [Perk.NEWSLETTER];
    }
}
 
class SilverTier implements CustomerTier {
    calculateDiscount(amount: Money): Money {
        return amount.multiply(0.10);
    }
    getPerks(): Perk[] {
        return [Perk.NEWSLETTER, Perk.EARLY_ACCESS];
    }
}
 
class GoldTier implements CustomerTier {
    calculateDiscount(amount: Money): Money {
        return amount.multiply(0.15).max(new Money(50));
    }
    getPerks(): Perk[] {
        return [Perk.NEWSLETTER, Perk.EARLY_ACCESS, Perk.PRIORITY_SUPPORT];
    }
}
 
class PlatinumTier implements CustomerTier {
    calculateDiscount(amount: Money): Money {
        return amount.multiply(0.20).max(new Money(100));
    }
    getPerks(): Perk[] {
        return [Perk.ALL];
    }
}
 
// Service becomes trivial — NO SWITCH
class DiscountService {
    calculateDiscount(tier: CustomerTier, amount: Money): Money {
        return tier.calculateDiscount(amount);  // Polymorphic call
    }
    
    getPerks(tier: CustomerTier): Perk[] {
        return tier.getPerks();  // Polymorphic call
    }
}
 
// Adding DiamondTier: create new class, no modifications to DiscountService

Where Does the Switch Go?

A common question: 'The switch has to exist somewhere—where does it go?'

The switch moves to the construction layer, which is typically:

Factory method/class: A factory that creates the right tier based on configuration
Dependency injection: Container configuration wires up the right implementations
Database/configuration mapping: Tier stored in database, factory creates instance

The key insight: the switch runs once at construction time, not repeatedly at every use site.

The Factory Pattern

Summary and Key Takeaways

We've thoroughly examined switch statements on type as an OCP violation pattern. Let's consolidate our understanding:

Key Takeaways

•Switch statements are isomorphic to if-else chains — Same OCP violation, different syntax. Don't be fooled by cleaner appearance.
•Switch appears in recognizable patterns — Enum dispatch, string discrimination, action/command handling. Learn to spot these.
•Language features add complexity — Fall-through behavior, exhaustiveness checking, pattern matching. Each requires awareness.
•Switch statements proliferate — One discriminator spawns switches throughout the codebase, creating multiplicative maintenance burden.
•State management patterns normalize switch — Redux/Vuex patterns trade OCP compliance for explicit state handling. Make conscious trade-offs.
•Not all switches are violations — Finite, closed sets (days, HTTP ranges) are acceptable. Open, extensible sets need polymorphism.
•The transformation is mechanical — Extract interface, create implementations, replace switch with polymorphic call, relocate construction.
•The factory contains the last switch — Transform data to objects once; use polymorphism everywhere else.

What's Next:

Page Complete

3 / 4