System Design (HLD)OCP Violations and Fixes

OCP Violations and Fixes

LevelIntermediate

Duration75 mins

TopicOCP Violations and Fixes

2 / 4

Type Checking with instanceof

The Type Safety Illusion

Developers working in statically-typed languages often believe they've escaped the pitfalls of type-based conditionals. After all, if the type system enforces correctness at compile time, why would we need runtime type checks?

Yet lurking in codebases across Java, TypeScript, C#, and other typed languages is a pervasive anti-pattern: instanceof checks (or their language equivalents: is in C#, typeof in TypeScript for primitives, as for type assertions). These runtime type interrogations represent a failure to leverage the type system properly—and a clear violation of the Open/Closed Principle.

The Core Problem:

When you write if (obj instanceof SpecificType), you're saying: "I received something typed as an abstraction, but I don't trust polymorphism to handle it correctly, so I'm going to explicitly check what it really is." This undermines the entire purpose of abstraction and forces modifications whenever new types are introduced.

What You Will Learn

By the end of this page, you will understand why instanceof checks violate OCP even in strongly-typed languages, recognize the various forms type checking takes across different languages, comprehend the architectural damage caused by runtime type inspection, and develop strategies for designing code that never needs to ask 'what type is this?'

The Mechanics of Type Inspection

Before analyzing why type checking violates OCP, let's understand exactly what happens when we interrogate types at runtime and how this manifests across different languages.

What instanceof Actually Does:

The instanceof operator (and its equivalents) performs a runtime check to determine whether an object is an instance of a particular class or implements a particular interface. This check traverses the object's prototype chain (or class hierarchy) to make the determination.

Language Variations:

Type Checking Operators Across Languages
Language	Operator/Syntax	Example	Notes
Java	`instanceof`	`if (shape instanceof Circle)`	Checks class hierarchy
TypeScript/JavaScript	`instanceof`	`if (payment instanceof CreditCard)`	Prototype chain check
C#	`is` / `as`	`if (vehicle is Car car)`	Pattern matching variant
Python	`isinstance()`	`if isinstance(animal, Dog)`	Also checks inheritance
Kotlin	`is`	`if (message is EmailMessage)`	Smart casting
Go	Type assertion	`if v, ok := i.(string); ok`	Interface type checks
Rust	`match` on enums	`match msg { Email(e) => ... }`	Discriminated unions

The Pattern in Practice:

Regardless of language, the structural anti-pattern looks remarkably similar:

instanceof-pattern.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
// The canonical instanceof OCP violation
abstract class Shape {
    abstract getType(): string;
}
 
class Circle extends Shape {
    constructor(public radius: number) { super(); }
    getType() { return 'circle'; }
}
 
class Rectangle extends Shape {
    constructor(public width: number, public height: number) { super(); }
    getType() { return 'rectangle'; }
}
 
class Triangle extends Shape {
    constructor(public base: number, public height: number) { super(); }
    getType() { return 'triangle'; }
}
 
// OCP VIOLATION: External code interrogating types
class ShapeCalculator {
    calculateArea(shape: Shape): number {
        if (shape instanceof Circle) {
            return Math.PI * shape.radius ** 2;
        } else if (shape instanceof Rectangle) {
            return shape.width * shape.height;
        } else if (shape instanceof Triangle) {
            return 0.5 * shape.base * shape.height;
        }
        
        throw new Error('Unknown shape type');
    }
    
    calculatePerimeter(shape: Shape): number {
        if (shape instanceof Circle) {
            return 2 * Math.PI * shape.radius;
        } else if (shape instanceof Rectangle) {
            return 2 * (shape.width + shape.height);
        } else if (shape instanceof Triangle) {
            // Assuming equilateral for simplicity
            return 3 * shape.base;
        }
        
        throw new Error('Unknown shape type');
    }
}

Why This Is Fundamentally Broken:

The Shape hierarchy was designed with polymorphism in mind—that's why Shape is abstract. Yet ShapeCalculator completely ignores this design. Instead of letting each shape calculate its own area, the calculator pulls the shape apart through type inspection and reimplements each shape's behavior externally.

This creates a knowledge coupling that shouldn't exist: ShapeCalculator must know every possible shape subclass, their properties, and their mathematical formulas. Add a Pentagon class? You must modify ShapeCalculator. Add a Hexagon? Modify it again. The abstraction provides no protection.

The Abstraction Betrayal

When you receive a parameter typed as Shape and then check instanceof Circle, you're declaring that the abstraction is insufficient. You're saying 'I know this is supposed to be any shape, but I actually need to know the specific type.' This betrays the contract the abstraction was meant to provide.

Why instanceof Violates OCP

Let's systematically analyze how instanceof checks violate both aspects of the Open/Closed Principle.

Violation of 'Closed for Modification':

Every method that contains instanceof checks against a type hierarchy becomes a modification target when that hierarchy expands. The ShapeCalculator class is not closed for modification—it's wide open. Adding Pentagon extends Shape requires:

Opening ShapeCalculator.ts
Adding else if (shape instanceof Pentagon) to calculateArea()
Adding the same to calculatePerimeter()
Adding the same to every other method that uses instanceof

The tested, deployed, stable code is reopened and modified.

modification-required.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
// Adding a new shape forces modification everywhere
class Pentagon extends Shape {
    constructor(public side: number) { super(); }
    getType() { return 'pentagon'; }
}
 
// Now ShapeCalculator MUST be modified:
class ShapeCalculator {
    calculateArea(shape: Shape): number {
        if (shape instanceof Circle) {
            return Math.PI * shape.radius ** 2;
        } else if (shape instanceof Rectangle) {
            return shape.width * shape.height;
        } else if (shape instanceof Triangle) {
            return 0.5 * shape.base * shape.height;
        } else if (shape instanceof Pentagon) {
            // NEW: Must add this branch
            return (shape.side ** 2 * Math.sqrt(25 + 10 * Math.sqrt(5))) / 4;
        }
        
        throw new Error('Unknown shape type');
    }
    
    // AND modify calculatePerimeter()
    // AND modify any other method that uses instanceof Shape
}

Violation of 'Open for Extension':

True openness for extension means: "I can add new behavior (new shape types) without touching existing code." With instanceof checks scattered throughout the codebase:

Third-party developers cannot extend your shape system without forking your code
Plugin architectures are impossible (plugins can't add shapes that existing code will handle)
The 'throw new Error' clause proves extensibility is impossible—unknown types cause runtime failures

The codebase is fundamentally closed to extension in any meaningful sense.

instanceof Approach

•Every new type = modify all consumers
•Behavior scattered across codebase
•Runtime failures for unknown types
•No plugin/extension capability
•Testing requires modifying shared code
•Type knowledge embedded in consumers

Polymorphic Approach

•Every new type = add new class only
•Behavior encapsulated in each type
•Compile-time completeness guarantees
•Plugins extend seamlessly
•Testing isolated per type
•Consumers know only abstraction

The Asymmetry Problem

instanceof creates asymmetric maintenance burdens. Adding a new shape type requires O(N) modifications where N is the number of places using instanceof. But with polymorphism, adding a new type is O(1)—just create the new class. As N grows, the instanceof approach becomes increasingly unsustainable.

Subtle Forms of Type Checking

While instanceof is the most obvious form of type checking, many violations hide behind more subtle patterns. Recognizing these disguised forms is crucial for identifying OCP violations in real codebases.

1. Type Assertions and Casting:

Using as in TypeScript or explicit casts in other languages often signals the same problem:

type-assertions.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// Type assertion masking the instanceof pattern
function processMessage(message: Message): void {
    // This is just instanceof with extra steps
    if (isEmailMessage(message)) {
        const email = message as EmailMessage;  // Cast after type guard
        sendViaSmtp(email.to, email.subject, email.body);
    } else if (isSMSMessage(message)) {
        const sms = message as SMSMessage;
        sendViaTwilio(sms.phoneNumber, sms.text);
    }
}
 
// User-defined type guards are often instanceof in disguise
function isEmailMessage(msg: Message): msg is EmailMessage {
    return msg instanceof EmailMessage;  // Hidden instanceof
}

2. 'Type' Property Checks:

Checking a discriminator property is architecturally identical to instanceof:

type-property.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// Type property discrimination - same problem, different syntax
interface Event {
    type: string;
    timestamp: Date;
}
 
function handleEvent(event: Event): void {
    // This is structurally identical to instanceof
    if (event.type === 'click') {
        // Handle click-specific properties
    } else if (event.type === 'scroll') {
        // Handle scroll-specific properties
    } else if (event.type === 'keypress') {
        // Handle keypress-specific properties
    }
    // Same violation: adding 'resize' event = modify this function
}

3. Constructor or Class Name Comparisons:

Some developers check constructor functions or class names directly:

constructor-checks.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// Constructor-based type checking - fragile and violation-prone
function serialize(entity: BaseEntity): string {
    if (entity.constructor.name === 'User') {
        return JSON.stringify({ type: 'user', data: entity });
    } else if (entity.constructor.name === 'Product') {
        return JSON.stringify({ type: 'product', data: entity });
    } else if (entity.constructor.name === 'Order') {
        return JSON.stringify({ type: 'order', data: entity });
    }
    throw new Error(`Cannot serialize ${entity.constructor.name}`);
}
 
// This is even MORE fragile than instanceof because:
// 1. Minification can change constructor names
// 2. String comparisons are typo-prone
// 3. No compile-time verification

4. 'is' Methods That Expose Internal Type:

Some codebases add methods that expose what type something is, then check externally:

is-methods.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// 'is' methods that enable external type checking
abstract class Vehicle {
    abstract isAircraft(): boolean;
    abstract isWatercraft(): boolean;
    abstract isLandVehicle(): boolean;
}
 
class Airplane extends Vehicle {
    isAircraft() { return true; }
    isWatercraft() { return false; }
    isLandVehicle() { return false; }
}
 
// Consumer checks these flags - same violation pattern
function calculateInsurance(vehicle: Vehicle): number {
    if (vehicle.isAircraft()) {
        return this.aviationInsuranceRate * this.getValue(vehicle);
    } else if (vehicle.isWatercraft()) {
        return this.marineInsuranceRate * this.getValue(vehicle);
    } else if (vehicle.isLandVehicle()) {
        return this.autoInsuranceRate * this.getValue(vehicle);
    }
}

The Litmus Test

Any code that asks 'what type is this?' before deciding what to do is likely an OCP violation. It doesn't matter if the question is asked via instanceof, string comparison, type property, or boolean flags—the architectural flaw is identical.

The Deeper Problem: Lost Polymorphism

Beyond the practical OCP violation, instanceof checks represent a deeper architectural problem: abandoned polymorphism. When we create class hierarchies but then check types externally, we've defeated the primary purpose of object-oriented design.

Polymorphism's Promise:

The entire point of inheritance and interfaces is that consuming code can work with abstractions without knowing concrete types. This provides:

Decoupling: Consumers don't depend on implementations
Substitutability: Any implementation can be used interchangeably
Extension: New implementations integrate without consumer changes

instanceof Breaks This Contract:

When code checks instanceof, it's explicitly requiring knowledge of concrete types. The abstraction becomes a façade—present in the type signature but ignored in the logic.

polymorphism-abandoned.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
// The abstraction provides no protection when instanceof is used
interface PaymentProcessor {
    process(transaction: Transaction): Result;
}
 
class PaymentService {
    constructor(private processor: PaymentProcessor) {}
    
    executePayment(transaction: Transaction): Result {
        // We receive an abstraction (PaymentProcessor)
        // But then immediately violate it:
        
        if (this.processor instanceof StripeProcessor) {
            // Stripe-specific handling
            return this.handleStripeSpecifics(this.processor, transaction);
        } else if (this.processor instanceof PayPalProcessor) {
            // PayPal-specific handling
            return this.handlePayPalSpecifics(this.processor, transaction);
        } else if (this.processor instanceof SquareProcessor) {
            // Square-specific handling
            return this.handleSquareSpecifics(this.processor, transaction);
        }
        
        // What's the point of the interface if we check types anyway?
        return this.processor.process(transaction);
    }
}
 
// The interface PaymentProcessor is now meaningless decoration.
// PaymentService is coupled to every concrete implementation.

Symptom of Insufficient Abstraction:

When developers reach for instanceof, it's often because the abstraction doesn't provide what they need. Common causes:

Missing methods on the interface: The interface doesn't expose necessary behavior, forcing external type checks
Leaky abstractions: Implementation details aren't properly hidden, tempting consumers to check types
Mixed concerns: The abstraction conflates things that should be separate
Afterthought polymorphism: The hierarchy was added to existing code without redesigning for true polymorphism

Questions to Ask When Tempted by instanceof

•Why don't I trust the abstraction? If the interface doesn't provide what I need, can I extend it?
•Should this behavior be on the types themselves? If I'm checking type to select behavior, should each type encapsulate that behavior?
•Am I missing a method on the interface? Could I add an abstract method that each type implements?
•Is this abstraction at the wrong level? Maybe I need multiple interfaces at different granularities?
•Could a visitor or strategy pattern help? These patterns formalize type-specific behavior without instanceof.

The Design Smell

Think of instanceof as a code smell that signals: 'My abstraction is insufficient for my needs.' The fix is rarely to add more instanceof checks—it's to improve the abstraction so the checks become unnecessary.

Real-World instanceof Disasters

Let's examine concrete scenarios where instanceof usage leads to significant maintenance problems, using examples from common application domains.

Example 1: The UI Component Nightmare

ui-disaster.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
// Real-world disaster: Layout engine using instanceof
abstract class UIComponent {
    abstract render(): void;
}
 
class LayoutEngine {
    layout(components: UIComponent[]): void {
        for (const component of components) {
            if (component instanceof TextComponent) {
                this.measureText(component);
                component.x = this.textLayoutAlgorithm(component);
            } else if (component instanceof ImageComponent) {
                this.loadImageDimensions(component);
                component.x = this.imageLayoutAlgorithm(component);
            } else if (component instanceof VideoComponent) {
                this.getVideoAspectRatio(component);
                component.x = this.videoLayoutAlgorithm(component);
            } else if (component instanceof ButtonComponent) {
                this.measureButtonContent(component);
                component.x = this.buttonLayoutAlgorithm(component);
            } else if (component instanceof ContainerComponent) {
                this.recursivelyLayoutChildren(component);
                component.x = this.containerLayoutAlgorithm(component);
            }
            // 20 more component types...
        }
    }
    
    // Every method in LayoutEngine has similar chains:
    handleClick(component: UIComponent, event: ClickEvent): void { /* same pattern */ }
    applyStyles(component: UIComponent, styles: Styles): void { /* same pattern */ }
    serialize(component: UIComponent): JSON { /* same pattern */ }
}
 
// Result: Adding ChartComponent, TabComponent, CarouselComponent...
// Each requires modifying EVERY method in LayoutEngine.
// The codebase becomes unmaintainable at ~50 component types.

Example 2: The Data Export Explosion

export-disaster.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
// Data export system with instanceof anti-pattern
interface Exportable {
    getId(): string;
}
 
class DataExporter {
    export(entities: Exportable[], format: ExportFormat): Buffer {
        const rows: any[][] = [];
        
        for (const entity of entities) {
            if (entity instanceof User) {
                rows.push([entity.email, entity.name, entity.createdAt]);
            } else if (entity instanceof Order) {
                rows.push([entity.orderId, entity.total, entity.status]);
            } else if (entity instanceof Product) {
                rows.push([entity.sku, entity.price, entity.inventory]);
            } else if (entity instanceof Invoice) {
                rows.push([entity.invoiceNumber, entity.amount, entity.dueDate]);
            } else if (entity instanceof Shipment) {
                rows.push([entity.trackingNumber, entity.carrier, entity.status]);
            }
            // New entity types = new branches
        }
        
        return this.formatOutput(rows, format);
    }
    
    // Also needed: getHeaders(), validateBeforeExport(), etc.
    // All with identical instanceof chains
    
    getHeaders(entityType: Exportable): string[] {
        if (entityType instanceof User) {
            return ['Email', 'Name', 'Created At'];
        } else if (entityType instanceof Order) {
            return ['Order ID', 'Total', 'Status'];
        }
        // ... repeat for every type
    }
}
 
// Adding "Subscription" exportable:
// - Modify export()
// - Modify getHeaders()
// - Modify validateBeforeExport()
// - Modify every other method that touches Exportable

Example 3: The Validation Labyrinth

validation-disaster.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
// Validation service riddled with instanceof
class ValidationService {
    validate(input: FormInput): ValidationResult {
        const errors: ValidationError[] = [];
        
        if (input instanceof EmailInput) {
            if (!this.isValidEmail(input.value)) {
                errors.push({ field: input.name, message: 'Invalid email' });
            }
        } else if (input instanceof PhoneInput) {
            if (!this.isValidPhone(input.value, input.countryCode)) {
                errors.push({ field: input.name, message: 'Invalid phone number' });
            }
        } else if (input instanceof DateInput) {
            if (!this.isValidDate(input.value, input.format)) {
                errors.push({ field: input.name, message: 'Invalid date' });
            }
            if (input.minDate && input.value < input.minDate) {
                errors.push({ field: input.name, message: 'Date too early' });
            }
        } else if (input instanceof CurrencyInput) {
            if (!this.isValidCurrency(input.value, input.currency)) {
                errors.push({ field: input.name, message: 'Invalid amount' });
            }
        } else if (input instanceof FileInput) {
            if (input.file.size > input.maxSize) {
                errors.push({ field: input.name, message: 'File too large' });
            }
            if (!input.allowedTypes.includes(input.file.type)) {
                errors.push({ field: input.name, message: 'Invalid file type' });
            }
        }
        // 30 more input types...
        
        return { valid: errors.length === 0, errors };
    }
}
 
// New input type (e.g., CreditCardInput, AddressInput):
// Must learn all the instanceof locations and modify each one

The Compounding Effect

In each example, the problem is not just the initial violation—it's the multiplication. If you have M methods with instanceof chains and N types, you have M×N pieces of type-specific logic. Adding type N+1 requires modifying M methods. Adding method M+1 requires handling N types. The complexity grows quadratically.

TypeScript-Specific Considerations

TypeScript introduces some nuances around type checking that deserve specific attention. The language's structural type system and discriminated unions offer alternatives, but they can also enable more sophisticated OCP violations.

Discriminated Unions: Power and Peril

TypeScript's discriminated unions are a powerful feature that enables exhaustive type checking:

discriminated-unions.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
// Discriminated union - safer than instanceof but still violates OCP
type Result = 
    | { status: 'success'; data: any }
    | { status: 'error'; error: Error }
    | { status: 'loading' }
    | { status: 'idle' };
 
function handleResult(result: Result): string {
    switch (result.status) {
        case 'success':
            return `Data: ${result.data}`;
        case 'error':
            return `Error: ${result.error.message}`;
        case 'loading':
            return 'Loading...';
        case 'idle':
            return 'Ready';
    }
}
 
// TypeScript provides exhaustiveness checking (good!)
// But adding a new status still requires modifying handleResult (OCP violation)
 
// Adding: | { status: 'cancelled'; reason: string }
// Compiler error in handleResult forces update - but update is still required

The Exhaustiveness Trade-off:

Discriminated unions provide compile-time exhaustiveness checking—TypeScript will error if you don't handle all cases. This is strictly better than instanceof because you can't accidentally miss a type. However, it's still an OCP violation because adding new union members requires modifying every switch statement.

When Discriminated Unions Are Acceptable:

Unlike open class hierarchies, some discriminated unions represent closed sets:

Closed Sets — Discriminated Unions OK

•Boolean alternatives: { type: 'yes' } | { type: 'no' } — there will never be a third option
•HTTP method types: 'GET' | 'POST' | 'PUT' | 'DELETE' | 'PATCH' — rarely expanded
•State machine states: If the state machine is finalized and fixed
•Mathematical cases: { type: 'positive' } | { type: 'negative' } | { type: 'zero' }
•Standard protocols: Handling known, standardized variants (HTTP status categories, etc.)

Open Sets — Prefer Polymorphism

•Payment types: New payment methods are constantly emerging (Apple Pay, crypto, BNPL, etc.)
•UI components: Component libraries continuously add new component types
•Plugin systems: The whole point is third-party extension
•Document formats: New formats appear (AVIF images, WebP, new document standards)
•Notification channels: Slack, Discord, Teams, WhatsApp — the list grows

typescript-patterns.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
// User-defined type guards - often hide instanceof
// Be suspicious of these patterns:
 
function isAdmin(user: User): user is Admin {
    return user instanceof Admin;  // instanceof hidden in type guard
}
 
function hasPermission(user: User, permission: string): boolean {
    if (isAdmin(user)) {
        return true;  // Admins have all permissions
    }
    if (isManager(user)) {
        return user.permissions.includes(permission);
    }
    if (isBasicUser(user)) {
        return basicPermissions.includes(permission);
    }
    return false;
}
 
// BETTER: Polymorphic approach
interface User {
    hasPermission(permission: string): boolean;
}
 
class Admin implements User {
    hasPermission(permission: string): boolean {
        return true;  // Encapsulated in the type
    }
}
 
class Manager implements User {
    constructor(private permissions: string[]) {}
    hasPermission(permission: string): boolean {
        return this.permissions.includes(permission);
    }
}

TypeScript Best Practice

Use discriminated unions for closed, finite sets where exhaustiveness checking is valuable and the set genuinely won't grow. Use interfaces and polymorphism for open sets where extension is expected. The question is always: 'Will this set expand over time?'

Toward the Solution

Now that we understand the problem deeply, let's preview the path forward. We'll explore detailed refactoring patterns in the final page of this module, but establishing the conceptual direction here provides important context.

The Core Transformation: Ask, Don't Tell

The fundamental shift is from interrogation to delegation:

Interrogation (instanceof): 'What type are you? Based on that, I'll do the right thing.'
Delegation (polymorphism): 'Please do the thing. I trust you know how.'

This shift moves type-specific knowledge from consumers to the types themselves.

transformation-preview.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
// BEFORE: Interrogation pattern
class ShapeCalculator {
    calculateArea(shape: Shape): number {
        if (shape instanceof Circle) {
            return Math.PI * shape.radius ** 2;
        } else if (shape instanceof Rectangle) {
            return shape.width * shape.height;
        }
        throw new Error('Unknown shape');
    }
}
 
// AFTER: Delegation pattern
interface Shape {
    calculateArea(): number;
}
 
class Circle implements Shape {
    constructor(private radius: number) {}
    calculateArea(): number {
        return Math.PI * this.radius ** 2;  // Circle knows how to calculate its area
    }
}
 
class Rectangle implements Shape {
    constructor(private width: number, private height: number) {}
    calculateArea(): number {
        return this.width * this.height;  // Rectangle knows how to calculate its area
    }
}
 
// Consumer becomes trivial
class ShapeService {
    getTotalArea(shapes: Shape[]): number {
        return shapes.reduce((total, shape) => total + shape.calculateArea(), 0);
    }
}
 
// Adding Pentagon: just implement Shape interface - no changes to ShapeService

Preview: Patterns That Eliminate instanceof

Several design patterns specifically address the need to eliminate type checking while maintaining polymorphic flexibility:

Design Patterns for Replacing instanceof
Pattern	Use Case	How It Helps
Strategy	Varying algorithms	Each strategy encapsulates its variant; consumer calls abstract method
Visitor	Operations on complex hierarchies	Types accept visitors; operations defined in visitor without instanceof
Abstract Factory	Creating family of objects	Factory produces concrete types; consumer works with abstractions
Template Method	Varying steps in algorithm	Base class defines skeleton; subclasses override specific steps
Command	Encapsulating requests	Each command type encapsulates its execution; dispatcher doesn't check types
Double Dispatch	Type-specific interaction	Both participants cooperate to determine behavior polymorphically

Looking Ahead

In the 'Refactoring to OCP-Compliant Design' page, we'll work through comprehensive refactoring examples using these patterns. For now, the key insight is: every instanceof check signals an opportunity to improve your object model.

Summary and Key Takeaways

We've conducted a thorough examination of instanceof as an OCP violation pattern. Let's consolidate our understanding:

Key Takeaways

•instanceof breaks OCP systematically — Every new type requires modifying every location that uses type checking.
•Type checking appears in many disguises — instanceof, type assertions, discriminator properties, constructor checks, and boolean type flags all represent the same anti-pattern.
•The real problem is abandoned polymorphism — Type checking signals that the abstraction is insufficient or being ignored.
•TypeScript discriminated unions have nuance — They're acceptable for closed sets but problematic for open sets that will grow.
•The solution is delegation, not interrogation — Move type-specific behavior into the types themselves.
•Design patterns formalize the solution — Strategy, Visitor, Abstract Factory, and others provide structured ways to eliminate type checking.
•instanceof is a design smell — Whenever you're tempted to use it, ask: 'What's wrong with my abstraction that makes this necessary?'

What's Next:

In the next page, we'll examine another pervasive OCP violation: switch statements on type. While conceptually similar to if-else chains, switch statements carry their own patterns, idioms, and refactoring approaches. We'll explore why switch is often the first construct developers reach for—and why it so frequently leads to maintenance nightmares.

Page Complete

You now understand instanceof as an OCP anti-pattern, can recognize its subtle forms, and have a conceptual foundation for designing instanceof-free code. Next: switch statements on type.

2 / 4

Loading learning content...

System Design (HLD)OCP Violations and Fixes

OCP Violations and Fixes

LevelIntermediate

Duration75 mins

TopicOCP Violations and Fixes

2 / 4

Type Checking with instanceof

The Type Safety Illusion

The Core Problem:

What You Will Learn

The Mechanics of Type Inspection

Before analyzing why type checking violates OCP, let's understand exactly what happens when we interrogate types at runtime and how this manifests across different languages.

What instanceof Actually Does:

Language Variations:

Type Checking Operators Across Languages
Language	Operator/Syntax	Example	Notes
Java	`instanceof`	`if (shape instanceof Circle)`	Checks class hierarchy
TypeScript/JavaScript	`instanceof`	`if (payment instanceof CreditCard)`	Prototype chain check
C#	`is` / `as`	`if (vehicle is Car car)`	Pattern matching variant
Python	`isinstance()`	`if isinstance(animal, Dog)`	Also checks inheritance
Kotlin	`is`	`if (message is EmailMessage)`	Smart casting
Go	Type assertion	`if v, ok := i.(string); ok`	Interface type checks
Rust	`match` on enums	`match msg { Email(e) => ... }`	Discriminated unions

The Pattern in Practice:

Regardless of language, the structural anti-pattern looks remarkably similar:

instanceof-pattern.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
// The canonical instanceof OCP violation
abstract class Shape {
    abstract getType(): string;
}
 
class Circle extends Shape {
    constructor(public radius: number) { super(); }
    getType() { return 'circle'; }
}
 
class Rectangle extends Shape {
    constructor(public width: number, public height: number) { super(); }
    getType() { return 'rectangle'; }
}
 
class Triangle extends Shape {
    constructor(public base: number, public height: number) { super(); }
    getType() { return 'triangle'; }
}
 
// OCP VIOLATION: External code interrogating types
class ShapeCalculator {
    calculateArea(shape: Shape): number {
        if (shape instanceof Circle) {
            return Math.PI * shape.radius ** 2;
        } else if (shape instanceof Rectangle) {
            return shape.width * shape.height;
        } else if (shape instanceof Triangle) {
            return 0.5 * shape.base * shape.height;
        }
        
        throw new Error('Unknown shape type');
    }
    
    calculatePerimeter(shape: Shape): number {
        if (shape instanceof Circle) {
            return 2 * Math.PI * shape.radius;
        } else if (shape instanceof Rectangle) {
            return 2 * (shape.width + shape.height);
        } else if (shape instanceof Triangle) {
            // Assuming equilateral for simplicity
            return 3 * shape.base;
        }
        
        throw new Error('Unknown shape type');
    }
}

Why This Is Fundamentally Broken:

The Abstraction Betrayal

Why instanceof Violates OCP

Let's systematically analyze how instanceof checks violate both aspects of the Open/Closed Principle.

Violation of 'Closed for Modification':

Opening ShapeCalculator.ts
Adding else if (shape instanceof Pentagon) to calculateArea()
Adding the same to calculatePerimeter()
Adding the same to every other method that uses instanceof

The tested, deployed, stable code is reopened and modified.

modification-required.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
// Adding a new shape forces modification everywhere
class Pentagon extends Shape {
    constructor(public side: number) { super(); }
    getType() { return 'pentagon'; }
}
 
// Now ShapeCalculator MUST be modified:
class ShapeCalculator {
    calculateArea(shape: Shape): number {
        if (shape instanceof Circle) {
            return Math.PI * shape.radius ** 2;
        } else if (shape instanceof Rectangle) {
            return shape.width * shape.height;
        } else if (shape instanceof Triangle) {
            return 0.5 * shape.base * shape.height;
        } else if (shape instanceof Pentagon) {
            // NEW: Must add this branch
            return (shape.side ** 2 * Math.sqrt(25 + 10 * Math.sqrt(5))) / 4;
        }
        
        throw new Error('Unknown shape type');
    }
    
    // AND modify calculatePerimeter()
    // AND modify any other method that uses instanceof Shape
}

Violation of 'Open for Extension':

True openness for extension means: "I can add new behavior (new shape types) without touching existing code." With instanceof checks scattered throughout the codebase:

Third-party developers cannot extend your shape system without forking your code
Plugin architectures are impossible (plugins can't add shapes that existing code will handle)
The 'throw new Error' clause proves extensibility is impossible—unknown types cause runtime failures

The codebase is fundamentally closed to extension in any meaningful sense.

instanceof Approach

•Every new type = modify all consumers
•Behavior scattered across codebase
•Runtime failures for unknown types
•No plugin/extension capability
•Testing requires modifying shared code
•Type knowledge embedded in consumers

Polymorphic Approach

•Every new type = add new class only
•Behavior encapsulated in each type
•Compile-time completeness guarantees
•Plugins extend seamlessly
•Testing isolated per type
•Consumers know only abstraction

The Asymmetry Problem

Subtle Forms of Type Checking

1. Type Assertions and Casting:

Using as in TypeScript or explicit casts in other languages often signals the same problem:

type-assertions.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// Type assertion masking the instanceof pattern
function processMessage(message: Message): void {
    // This is just instanceof with extra steps
    if (isEmailMessage(message)) {
        const email = message as EmailMessage;  // Cast after type guard
        sendViaSmtp(email.to, email.subject, email.body);
    } else if (isSMSMessage(message)) {
        const sms = message as SMSMessage;
        sendViaTwilio(sms.phoneNumber, sms.text);
    }
}
 
// User-defined type guards are often instanceof in disguise
function isEmailMessage(msg: Message): msg is EmailMessage {
    return msg instanceof EmailMessage;  // Hidden instanceof
}

2. 'Type' Property Checks:

Checking a discriminator property is architecturally identical to instanceof:

type-property.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// Type property discrimination - same problem, different syntax
interface Event {
    type: string;
    timestamp: Date;
}
 
function handleEvent(event: Event): void {
    // This is structurally identical to instanceof
    if (event.type === 'click') {
        // Handle click-specific properties
    } else if (event.type === 'scroll') {
        // Handle scroll-specific properties
    } else if (event.type === 'keypress') {
        // Handle keypress-specific properties
    }
    // Same violation: adding 'resize' event = modify this function
}

3. Constructor or Class Name Comparisons:

Some developers check constructor functions or class names directly:

constructor-checks.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// Constructor-based type checking - fragile and violation-prone
function serialize(entity: BaseEntity): string {
    if (entity.constructor.name === 'User') {
        return JSON.stringify({ type: 'user', data: entity });
    } else if (entity.constructor.name === 'Product') {
        return JSON.stringify({ type: 'product', data: entity });
    } else if (entity.constructor.name === 'Order') {
        return JSON.stringify({ type: 'order', data: entity });
    }
    throw new Error(`Cannot serialize ${entity.constructor.name}`);
}
 
// This is even MORE fragile than instanceof because:
// 1. Minification can change constructor names
// 2. String comparisons are typo-prone
// 3. No compile-time verification

4. 'is' Methods That Expose Internal Type:

Some codebases add methods that expose what type something is, then check externally:

is-methods.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// 'is' methods that enable external type checking
abstract class Vehicle {
    abstract isAircraft(): boolean;
    abstract isWatercraft(): boolean;
    abstract isLandVehicle(): boolean;
}
 
class Airplane extends Vehicle {
    isAircraft() { return true; }
    isWatercraft() { return false; }
    isLandVehicle() { return false; }
}
 
// Consumer checks these flags - same violation pattern
function calculateInsurance(vehicle: Vehicle): number {
    if (vehicle.isAircraft()) {
        return this.aviationInsuranceRate * this.getValue(vehicle);
    } else if (vehicle.isWatercraft()) {
        return this.marineInsuranceRate * this.getValue(vehicle);
    } else if (vehicle.isLandVehicle()) {
        return this.autoInsuranceRate * this.getValue(vehicle);
    }
}

The Litmus Test

The Deeper Problem: Lost Polymorphism

Polymorphism's Promise:

The entire point of inheritance and interfaces is that consuming code can work with abstractions without knowing concrete types. This provides:

Decoupling: Consumers don't depend on implementations
Substitutability: Any implementation can be used interchangeably
Extension: New implementations integrate without consumer changes

instanceof Breaks This Contract:

When code checks instanceof, it's explicitly requiring knowledge of concrete types. The abstraction becomes a façade—present in the type signature but ignored in the logic.

polymorphism-abandoned.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
// The abstraction provides no protection when instanceof is used
interface PaymentProcessor {
    process(transaction: Transaction): Result;
}
 
class PaymentService {
    constructor(private processor: PaymentProcessor) {}
    
    executePayment(transaction: Transaction): Result {
        // We receive an abstraction (PaymentProcessor)
        // But then immediately violate it:
        
        if (this.processor instanceof StripeProcessor) {
            // Stripe-specific handling
            return this.handleStripeSpecifics(this.processor, transaction);
        } else if (this.processor instanceof PayPalProcessor) {
            // PayPal-specific handling
            return this.handlePayPalSpecifics(this.processor, transaction);
        } else if (this.processor instanceof SquareProcessor) {
            // Square-specific handling
            return this.handleSquareSpecifics(this.processor, transaction);
        }
        
        // What's the point of the interface if we check types anyway?
        return this.processor.process(transaction);
    }
}
 
// The interface PaymentProcessor is now meaningless decoration.
// PaymentService is coupled to every concrete implementation.

Symptom of Insufficient Abstraction:

When developers reach for instanceof, it's often because the abstraction doesn't provide what they need. Common causes:

Missing methods on the interface: The interface doesn't expose necessary behavior, forcing external type checks
Leaky abstractions: Implementation details aren't properly hidden, tempting consumers to check types
Mixed concerns: The abstraction conflates things that should be separate
Afterthought polymorphism: The hierarchy was added to existing code without redesigning for true polymorphism

Questions to Ask When Tempted by instanceof

•Why don't I trust the abstraction? If the interface doesn't provide what I need, can I extend it?
•Should this behavior be on the types themselves? If I'm checking type to select behavior, should each type encapsulate that behavior?
•Am I missing a method on the interface? Could I add an abstract method that each type implements?
•Is this abstraction at the wrong level? Maybe I need multiple interfaces at different granularities?
•Could a visitor or strategy pattern help? These patterns formalize type-specific behavior without instanceof.

The Design Smell

Real-World instanceof Disasters

Let's examine concrete scenarios where instanceof usage leads to significant maintenance problems, using examples from common application domains.

Example 1: The UI Component Nightmare

ui-disaster.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
// Real-world disaster: Layout engine using instanceof
abstract class UIComponent {
    abstract render(): void;
}
 
class LayoutEngine {
    layout(components: UIComponent[]): void {
        for (const component of components) {
            if (component instanceof TextComponent) {
                this.measureText(component);
                component.x = this.textLayoutAlgorithm(component);
            } else if (component instanceof ImageComponent) {
                this.loadImageDimensions(component);
                component.x = this.imageLayoutAlgorithm(component);
            } else if (component instanceof VideoComponent) {
                this.getVideoAspectRatio(component);
                component.x = this.videoLayoutAlgorithm(component);
            } else if (component instanceof ButtonComponent) {
                this.measureButtonContent(component);
                component.x = this.buttonLayoutAlgorithm(component);
            } else if (component instanceof ContainerComponent) {
                this.recursivelyLayoutChildren(component);
                component.x = this.containerLayoutAlgorithm(component);
            }
            // 20 more component types...
        }
    }
    
    // Every method in LayoutEngine has similar chains:
    handleClick(component: UIComponent, event: ClickEvent): void { /* same pattern */ }
    applyStyles(component: UIComponent, styles: Styles): void { /* same pattern */ }
    serialize(component: UIComponent): JSON { /* same pattern */ }
}
 
// Result: Adding ChartComponent, TabComponent, CarouselComponent...
// Each requires modifying EVERY method in LayoutEngine.
// The codebase becomes unmaintainable at ~50 component types.

Example 2: The Data Export Explosion

export-disaster.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
// Data export system with instanceof anti-pattern
interface Exportable {
    getId(): string;
}
 
class DataExporter {
    export(entities: Exportable[], format: ExportFormat): Buffer {
        const rows: any[][] = [];
        
        for (const entity of entities) {
            if (entity instanceof User) {
                rows.push([entity.email, entity.name, entity.createdAt]);
            } else if (entity instanceof Order) {
                rows.push([entity.orderId, entity.total, entity.status]);
            } else if (entity instanceof Product) {
                rows.push([entity.sku, entity.price, entity.inventory]);
            } else if (entity instanceof Invoice) {
                rows.push([entity.invoiceNumber, entity.amount, entity.dueDate]);
            } else if (entity instanceof Shipment) {
                rows.push([entity.trackingNumber, entity.carrier, entity.status]);
            }
            // New entity types = new branches
        }
        
        return this.formatOutput(rows, format);
    }
    
    // Also needed: getHeaders(), validateBeforeExport(), etc.
    // All with identical instanceof chains
    
    getHeaders(entityType: Exportable): string[] {
        if (entityType instanceof User) {
            return ['Email', 'Name', 'Created At'];
        } else if (entityType instanceof Order) {
            return ['Order ID', 'Total', 'Status'];
        }
        // ... repeat for every type
    }
}
 
// Adding "Subscription" exportable:
// - Modify export()
// - Modify getHeaders()
// - Modify validateBeforeExport()
// - Modify every other method that touches Exportable

Example 3: The Validation Labyrinth

validation-disaster.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
// Validation service riddled with instanceof
class ValidationService {
    validate(input: FormInput): ValidationResult {
        const errors: ValidationError[] = [];
        
        if (input instanceof EmailInput) {
            if (!this.isValidEmail(input.value)) {
                errors.push({ field: input.name, message: 'Invalid email' });
            }
        } else if (input instanceof PhoneInput) {
            if (!this.isValidPhone(input.value, input.countryCode)) {
                errors.push({ field: input.name, message: 'Invalid phone number' });
            }
        } else if (input instanceof DateInput) {
            if (!this.isValidDate(input.value, input.format)) {
                errors.push({ field: input.name, message: 'Invalid date' });
            }
            if (input.minDate && input.value < input.minDate) {
                errors.push({ field: input.name, message: 'Date too early' });
            }
        } else if (input instanceof CurrencyInput) {
            if (!this.isValidCurrency(input.value, input.currency)) {
                errors.push({ field: input.name, message: 'Invalid amount' });
            }
        } else if (input instanceof FileInput) {
            if (input.file.size > input.maxSize) {
                errors.push({ field: input.name, message: 'File too large' });
            }
            if (!input.allowedTypes.includes(input.file.type)) {
                errors.push({ field: input.name, message: 'Invalid file type' });
            }
        }
        // 30 more input types...
        
        return { valid: errors.length === 0, errors };
    }
}
 
// New input type (e.g., CreditCardInput, AddressInput):
// Must learn all the instanceof locations and modify each one

The Compounding Effect

TypeScript-Specific Considerations

Discriminated Unions: Power and Peril

TypeScript's discriminated unions are a powerful feature that enables exhaustive type checking:

discriminated-unions.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
// Discriminated union - safer than instanceof but still violates OCP
type Result = 
    | { status: 'success'; data: any }
    | { status: 'error'; error: Error }
    | { status: 'loading' }
    | { status: 'idle' };
 
function handleResult(result: Result): string {
    switch (result.status) {
        case 'success':
            return `Data: ${result.data}`;
        case 'error':
            return `Error: ${result.error.message}`;
        case 'loading':
            return 'Loading...';
        case 'idle':
            return 'Ready';
    }
}
 
// TypeScript provides exhaustiveness checking (good!)
// But adding a new status still requires modifying handleResult (OCP violation)
 
// Adding: | { status: 'cancelled'; reason: string }
// Compiler error in handleResult forces update - but update is still required

The Exhaustiveness Trade-off:

When Discriminated Unions Are Acceptable:

Unlike open class hierarchies, some discriminated unions represent closed sets:

Closed Sets — Discriminated Unions OK

•Boolean alternatives: { type: 'yes' } | { type: 'no' } — there will never be a third option
•HTTP method types: 'GET' | 'POST' | 'PUT' | 'DELETE' | 'PATCH' — rarely expanded
•State machine states: If the state machine is finalized and fixed
•Mathematical cases: { type: 'positive' } | { type: 'negative' } | { type: 'zero' }
•Standard protocols: Handling known, standardized variants (HTTP status categories, etc.)

Open Sets — Prefer Polymorphism

•Payment types: New payment methods are constantly emerging (Apple Pay, crypto, BNPL, etc.)
•UI components: Component libraries continuously add new component types
•Plugin systems: The whole point is third-party extension
•Document formats: New formats appear (AVIF images, WebP, new document standards)
•Notification channels: Slack, Discord, Teams, WhatsApp — the list grows

typescript-patterns.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
// User-defined type guards - often hide instanceof
// Be suspicious of these patterns:
 
function isAdmin(user: User): user is Admin {
    return user instanceof Admin;  // instanceof hidden in type guard
}
 
function hasPermission(user: User, permission: string): boolean {
    if (isAdmin(user)) {
        return true;  // Admins have all permissions
    }
    if (isManager(user)) {
        return user.permissions.includes(permission);
    }
    if (isBasicUser(user)) {
        return basicPermissions.includes(permission);
    }
    return false;
}
 
// BETTER: Polymorphic approach
interface User {
    hasPermission(permission: string): boolean;
}
 
class Admin implements User {
    hasPermission(permission: string): boolean {
        return true;  // Encapsulated in the type
    }
}
 
class Manager implements User {
    constructor(private permissions: string[]) {}
    hasPermission(permission: string): boolean {
        return this.permissions.includes(permission);
    }
}

TypeScript Best Practice

Toward the Solution

The Core Transformation: Ask, Don't Tell

The fundamental shift is from interrogation to delegation:

Interrogation (instanceof): 'What type are you? Based on that, I'll do the right thing.'
Delegation (polymorphism): 'Please do the thing. I trust you know how.'

This shift moves type-specific knowledge from consumers to the types themselves.

transformation-preview.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
// BEFORE: Interrogation pattern
class ShapeCalculator {
    calculateArea(shape: Shape): number {
        if (shape instanceof Circle) {
            return Math.PI * shape.radius ** 2;
        } else if (shape instanceof Rectangle) {
            return shape.width * shape.height;
        }
        throw new Error('Unknown shape');
    }
}
 
// AFTER: Delegation pattern
interface Shape {
    calculateArea(): number;
}
 
class Circle implements Shape {
    constructor(private radius: number) {}
    calculateArea(): number {
        return Math.PI * this.radius ** 2;  // Circle knows how to calculate its area
    }
}
 
class Rectangle implements Shape {
    constructor(private width: number, private height: number) {}
    calculateArea(): number {
        return this.width * this.height;  // Rectangle knows how to calculate its area
    }
}
 
// Consumer becomes trivial
class ShapeService {
    getTotalArea(shapes: Shape[]): number {
        return shapes.reduce((total, shape) => total + shape.calculateArea(), 0);
    }
}
 
// Adding Pentagon: just implement Shape interface - no changes to ShapeService

Preview: Patterns That Eliminate instanceof

Several design patterns specifically address the need to eliminate type checking while maintaining polymorphic flexibility:

Design Patterns for Replacing instanceof
Pattern	Use Case	How It Helps
Strategy	Varying algorithms	Each strategy encapsulates its variant; consumer calls abstract method
Visitor	Operations on complex hierarchies	Types accept visitors; operations defined in visitor without instanceof
Abstract Factory	Creating family of objects	Factory produces concrete types; consumer works with abstractions
Template Method	Varying steps in algorithm	Base class defines skeleton; subclasses override specific steps
Command	Encapsulating requests	Each command type encapsulates its execution; dispatcher doesn't check types
Double Dispatch	Type-specific interaction	Both participants cooperate to determine behavior polymorphically

Looking Ahead

Summary and Key Takeaways

We've conducted a thorough examination of instanceof as an OCP violation pattern. Let's consolidate our understanding:

Key Takeaways

•instanceof breaks OCP systematically — Every new type requires modifying every location that uses type checking.
•Type checking appears in many disguises — instanceof, type assertions, discriminator properties, constructor checks, and boolean type flags all represent the same anti-pattern.
•The real problem is abandoned polymorphism — Type checking signals that the abstraction is insufficient or being ignored.
•TypeScript discriminated unions have nuance — They're acceptable for closed sets but problematic for open sets that will grow.
•The solution is delegation, not interrogation — Move type-specific behavior into the types themselves.
•Design patterns formalize the solution — Strategy, Visitor, Abstract Factory, and others provide structured ways to eliminate type checking.
•instanceof is a design smell — Whenever you're tempted to use it, ask: 'What's wrong with my abstraction that makes this necessary?'

What's Next:

Page Complete

You now understand instanceof as an OCP anti-pattern, can recognize its subtle forms, and have a conceptual foundation for designing instanceof-free code. Next: switch statements on type.

2 / 4