Type Checking in Client Code — The Symptom of LSP Violations - Detecting And Fixing Lsp Violations | OneNoughtOne

0/246

System Design (LLD)Liskov Substitution Principle

Detecting and Fixing LSP Violations

LevelIntermediate

Duration75 mins

TopicLiskov Substitution Principle

1 / 4

Type Checking in Client Code — The Symptom of LSP Violations

When Your Code Becomes a Type Detective

You're reviewing a pull request when something catches your eye. A colleague has added this method to a payment processing service:

function processPayment(payment: Payment): Result {
    if (payment instanceof CreditCardPayment) {
        return processCreditCard(payment);
    } else if (payment instanceof PayPalPayment) {
        return processPayPal(payment);
    } else if (payment instanceof CryptoPayment) {
        return processCrypto(payment);
    } else {
        throw new Error("Unknown payment type");
    }
}

On the surface, this looks functional. It handles all current payment types. The code compiles. Tests pass. But experienced engineers feel an immediate sense of unease seeing code like this.

Why? Because this pattern—checking the concrete type of an object at runtime—is one of the most reliable indicators that something is fundamentally wrong with the design. It signals that the Payment abstraction has failed. The type hierarchy isn't working. Polymorphism has been abandoned.

This is the type checking smell, and it's your first and most reliable detector for Liskov Substitution Principle violations.

What You Will Learn

By the end of this page, you will understand why type checking in client code is a critical design smell, how to recognize its various forms, why it indicates LSP violations rather than just style issues, and how to systematically eliminate it through proper abstraction design.

Understanding the Type Checking Smell

When client code uses instanceof, typeof, type guards, or similar mechanisms to determine an object's concrete type before deciding how to interact with it, we call this the type checking smell. It appears in several forms:

Forms of Type Checking

•instanceof chains — Explicit checks against concrete class types
•Type switch/match statements — Branching on discriminated unions or type tags
•Type guards with side effects — Functions that check type and perform different actions
•Capability checking — Testing if an object 'has' a method before calling it
•Type fields/discriminators — Objects carrying their own type information for client inspection
•Defensive casting — Type assertions followed by type-specific logic

type-checking-variants
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
// VARIANT 1: instanceof chains
function 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");
}
 
// VARIANT 2: Type discriminator field
interface Shape {
    type: "circle" | "rectangle" | "triangle";
}
 
function calculateArea(shape: Shape): number {
    switch (shape.type) {
        case "circle":
            return Math.PI * (shape as Circle).radius ** 2;
        case "rectangle":
            return (shape as Rectangle).width * (shape as Rectangle).height;
        case "triangle":
            return 0.5 * (shape as Triangle).base * (shape as Triangle).height;
    }
}
 
// VARIANT 3: Capability checking
function exportShape(shape: Shape): void {
    if ('exportToSvg' in shape && typeof shape.exportToSvg === 'function') {
        shape.exportToSvg();
    } else if ('exportToPng' in shape && typeof shape.exportToPng === 'function') {
        shape.exportToPng();
    } else {
        throw new Error("Shape cannot be exported");
    }
}
 
// VARIANT 4: Defensive casting
function processNotification(notification: Notification): void {
    const email = notification as EmailNotification;
    if (email.emailAddress) {
        sendEmail(email);
    } else {
        const sms = notification as SmsNotification;
        if (sms.phoneNumber) {
            sendSms(sms);
        }
    }
}

Each variant expresses the same fundamental problem: the code that consumes the abstraction doesn't trust the abstraction to handle the operation uniformly. Instead, it inspects the concrete type and implements different logic for each case.

This distrust isn't irrational—it exists because the abstraction isn't providing what the client needs. The type hierarchy has failed to capture the behavioral commonality that would make uniform treatment possible.

Why Type Checking Indicates LSP Violations

Type checking in client code isn't merely a style issue or a minor design smell—it's a direct consequence of LSP violations. Let's understand the causal chain:

The LSP promise: If S is a subtype of T, then code written against T should work unchanged with any S.

What this means for methods: Every method on T should be safely callable on any subtype, producing consistent behavior that the caller can rely upon.

When LSP is violated: One or more subtypes don't fulfill the behavioral contract of the parent. They might:

Throw exceptions where the parent doesn't
Return different structures or null where the parent returns data
Have preconditions the parent doesn't require
Behave in ways the parent's contract doesn't anticipate

The client's forced response: When subtypes don't behave uniformly, client code must compensate. It cannot call methods blindly—it must first determine which subtype it has, then apply type-specific handling.

From LSP Violation to Type Checking
LSP Violation Pattern	Client's Forced Workaround	Type Check Manifestation
Subtype throws exception for unsupported operation	Must check type before calling	`if (!(shape instanceof NonRotatable)) shape.rotate()`
Subtype returns null where parent returns value	Must check type and handle null conditionally	`if (payment instanceof CashPayment) return 0; return payment.getTransactionId()`
Subtype has different behavior for same method	Must branch logic by type	`if (user instanceof AdminUser) processAdmin(user); else processRegular(user)`
Subtype requires additional preconditions	Must check type to validate properly	`if (doc instanceof SecureDocument) validateAccess(doc); doc.open()`
Subtype provides extended capabilities	Must check type to access extensions	`if (vehicle instanceof ElectricVehicle) vehicle.chargeBattery()`

The Type Check as Diagnostic Tool

Think of type checks as symptoms, not diseases. When you see an instanceof check, don't just remove it—ask why it exists. Someone added it because the abstraction wasn't providing what they needed. The type check is evidence of an underlying design problem.

The causality runs in one direction:

LSP Violation → Subtypes don't behave uniformly → Client can't rely on abstraction → Type checking becomes necessary

This means you cannot fix the problem by simply removing type checks. If you delete the instanceof statements without addressing the underlying LSP violation, you'll get runtime errors, crashes, or incorrect behavior. The type checks exist for a reason—they're compensating for broken polymorphism.

The real fix requires fixing the abstraction itself.

The Hidden Costs of Type-Checking Code

Type checking might seem like a pragmatic solution—"just add an instanceof check and move on." But this approach carries severe costs that compound over time, eventually creating architectural debt that becomes extremely expensive to address.

Costs of Type Checking in Client Code

•Violation of Open-Closed Principle — Every new subtype requires modifying every place that does type checking. Adding BankTransferPayment means hunting down and updating every instanceof chain.
•Scattered knowledge — Understanding how a type is handled requires examining every consumer. There's no single source of truth for a type's behavior—it's distributed across the codebase.
•Missing case bugs — When a new subtype is added, it's easy to miss some instanceof chains. The compiler can't help; these become runtime bugs that may not surface until production.
•Testing complexity explosion — Each type check multiplies branches. With 5 subtypes and 10 methods doing type checks, you have 50 code paths to test instead of 10.
•Refactoring resistance — Type checks create tight coupling to concrete types. Restructuring the hierarchy means updating every consumer, making evolution expensive.
•Lost abstraction benefits — The whole point of abstraction is to hide details. Type checks expose details to every consumer, negating the abstraction's value.

ocp-violation-chain
TypeScript
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
// The OCP disaster: Every location needs updating for new types
 
// Location 1: API Handler
function handlePaymentRequest(payment: Payment): Response {
    if (payment instanceof CreditCardPayment) { /* ... */ }
    else if (payment instanceof PayPalPayment) { /* ... */ }
    else if (payment instanceof CryptoPayment) { /* ... */ }
    // NEW TYPE: Must add BankTransferPayment case
}
 
// Location 2: Validation Service
function validatePayment(payment: Payment): ValidationResult {
    if (payment instanceof CreditCardPayment) { /* card-specific validation */ }
    else if (payment instanceof PayPalPayment) { /* paypal-specific validation */ }
    else if (payment instanceof CryptoPayment) { /* crypto-specific validation */ }
    // NEW TYPE: Must add BankTransferPayment case
}
 
// Location 3: Risk Assessment
function assessRisk(payment: Payment): RiskScore {
    if (payment instanceof CreditCardPayment) { /* card risk */ }
    else if (payment instanceof PayPalPayment) { /* paypal risk */ }
    else if (payment instanceof CryptoPayment) { /* crypto risk */ }
    // NEW TYPE: Must add BankTransferPayment case
}
 
// Location 4: Reporting
function getPaymentCategory(payment: Payment): string {
    if (payment instanceof CreditCardPayment) return "card";
    if (payment instanceof PayPalPayment) return "digital_wallet";
    if (payment instanceof CryptoPayment) return "cryptocurrency";
    // NEW TYPE: Must add BankTransferPayment case
}
 
// Location 5: Refund Handler
function processRefund(payment: Payment): RefundResult {
    if (payment instanceof CreditCardPayment) { /* card refund */ }
    else if (payment instanceof PayPalPayment) { /* paypal refund */ }
    else if (payment instanceof CryptoPayment) { /* crypto refund */ }
    // NEW TYPE: Must add BankTransferPayment case
}
 
// PROBLEM: Adding one new payment type requires changing 5+ files
// PROBLEM: Forgetting one location creates a silent bug
// PROBLEM: The compiler cannot help you find all locations

The arithmetic of type-checking debt:

Consider a system with:

10 payment types
20 functions that include type checks
Each function averages 15 lines per type-specific branch

Current state: 20 functions × 10 types × 15 lines = 3,000 lines of type-specific code

Adding one new type: 20 functions need modification = 20 PRs or one massive PR with 300+ new lines

Removing one type: Same 20 locations need updating

Restructuring the hierarchy: Every function must be rewritten

As the system grows, this pattern creates exponential complexity. What starts as "pragmatic" becomes an architectural straitjacket.

Technical Debt Compounding

Type checks breed more type checks. Once the pattern exists, it becomes the path of least resistance for handling new requirements. Each addition makes the proper fix more expensive, creating a debt spiral that can eventually require ground-up rewrites.

Recognizing Type Checking in Real Codebases

Type checking doesn't always appear as obvious instanceof chains. In production codebases, it manifests in subtler forms that are equally problematic. Learning to recognize these patterns is essential for effective code review and refactoring.

Obvious Type Checks

•instanceof keyword usage
•typeof on object fields
•Type discriminator fields
•Switch on class names
•Explicit type assertions

Subtle Type Checks

•Capability flags (.supportsFeature())
•String-based method dispatch
•Factory methods examining type
•Visitors with type-specific handlers
•Configuration maps keyed by type

subtle-type-checking
TypeScript
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
// SUBTLE FORM 1: Capability flags
class Document {
    supportsPrinting: boolean = false;
    supportsEditing: boolean = false;
    
    print(): void {
        if (!this.supportsPrinting) {
            throw new Error("Printing not supported");
        }
        // This IS type checking - checking capability IS checking type
    }
}
 
// Client must check:
if (doc.supportsPrinting) {
    doc.print();  // Still a type check in disguise!
}
 
// SUBTLE FORM 2: Strategy maps keyed by type
const paymentProcessors: Record<string, PaymentProcessor> = {
    'CreditCardPayment': new CreditCardProcessor(),
    'PayPalPayment': new PayPalProcessor(),
    'CryptoPayment': new CryptoProcessor(),
};
 
function process(payment: Payment): void {
    const processor = paymentProcessors[payment.constructor.name];
    // Using constructor.name IS instanceof in disguise
    if (!processor) throw new Error("Unknown payment type");
    processor.process(payment);
}
 
// SUBTLE FORM 3: Method existence checking
function exportDocument(doc: Document): void {
    // Duck typing IS type checking
    if ('toHtml' in doc) {
        return (doc as any).toHtml();
    }
    if ('toMarkdown' in doc) {
        return (doc as any).toMarkdown();
    }
    throw new Error("No export capability");
}
 
// SUBTLE FORM 4: Visitor accepting concrete types
interface ShapeVisitor {
    visitCircle(circle: Circle): void;
    visitRectangle(rect: Rectangle): void;
    visitTriangle(tri: Triangle): void;
    // Still type-aware! Just moves the checks to dispatch
}
 
// SUBTLE FORM 5: Type-based factory selection
function createHandler(entity: Entity): Handler {
    // Even "clean" factory patterns can hide type checking
    const handlerType = HANDLER_REGISTRY[entity.getType()];
    return new handlerType(entity);
}

The common thread: In each case, the client code is making decisions based on the concrete type of an object rather than treating all instances of the abstraction uniformly.

Key insight: The Visitor pattern (Form 4) is interesting because it's sometimes presented as a "proper" solution. But the Visitor pattern is embracing type checking rather than eliminating it—it formalizes the double dispatch that instanceof provides. This can be appropriate when you genuinely need type-specific behavior external to the types themselves, but it doesn't solve LSP violations.

When is type checking acceptable?

Legitimate Type Checking Scenarios

•Serialization/Deserialization — When reconstructing objects from data, you must determine the concrete type
•IDE/Tooling — Code analysis tools legitimately need to inspect types
•Debugging/Logging — Diagnostic code may reasonably include type information
•Interop boundaries — When integrating with external systems that don't share your type system
•True polymorphic extensions — When adding genuinely new capabilities not in the base contract (e.g., optional optimizations)

The Difference

Legitimate type checking occurs at system boundaries or in infrastructure code. Problematic type checking occurs in business logic where polymorphism should be handling the variation. Ask: 'Should this code need to know the concrete type?' If the answer is no, you've found an LSP violation symptom.

Systematic Detection Strategies

Finding type checks in large codebases requires systematic approaches. Here are proven strategies used by experienced engineers to surface LSP violations hidden in production code.

Detection Techniques

•Static Analysis / Grep — Search for instanceof, typeof, .constructor.name, type discriminator patterns
•Code Coverage Analysis — Look for methods with multiple branches where coverage varies by subtype—indicates type-specific paths
•Dependency Graph Analysis — If many modules depend on concrete types rather than abstractions, type checking likely exists
•Test Pattern Analysis — Tests that create specific subtypes and assert type-specific behavior indicate type coupling
•Change Impact Analysis — Track what changes when a new subtype is added. If many files change, type checking is distributed

detection-grep-patterns
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# Find instanceof usage
grep -rn "instanceof" --include="*.ts" --include="*.tsx" src/
 
# Find type discriminator patterns
grep -rn "\.type ===" --include="*.ts" src/
grep -rn "\[.*\.type\]" --include="*.ts" src/
 
# Find constructor.name usage
grep -rn "constructor\.name" --include="*.ts" src/
 
# Find typeof on objects (not primitives)
grep -rn "typeof.*=== ['"]object['"]" --include="*.ts" src/
 
# Find 'in' operator for capability checking
grep -rn "if.*'\w\+' in " --include="*.ts" src/
 
# Find hasOwnProperty checks
grep -rn "hasOwnProperty" --include="*.ts" src/
 
# Count occurrences by file to find hotspots
grep -rn "instanceof" --include="*.ts" src/ | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

Automated detection with linting rules:

Many organizations create custom ESLint or similar rules to catch type checking patterns during development:

custom-lint-rule
TypeScript
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
// Example ESLint rule structure for detecting instanceof in business logic
// Note: This is pseudocode illustrating the concept
 
const lspInstanceofRule = {
    meta: {
        type: "suggestion",
        docs: {
            description: "Warn against instanceof in business logic (LSP violation symptom)",
        },
    },
    create(context) {
        return {
            BinaryExpression(node) {
                if (node.operator === "instanceof") {
                    // Check if we're in business logic (not serialization, tests, etc.)
                    const filePath = context.getFilename();
                    
                    if (!isInfrastructureCode(filePath) && !isTestCode(filePath)) {
                        context.report({
                            node,
                            message: "instanceof in business logic suggests LSP violation. " +
                                     "Consider polymorphic dispatch instead.",
                        });
                    }
                }
            },
        };
    },
};
 
// Companion rule for type discriminators
const lspTypeDiscriminatorRule = {
    create(context) {
        return {
            SwitchStatement(node) {
                // Check if switching on a .type property
                if (isTypeDiscriminatorSwitch(node)) {
                    context.report({
                        node,
                        message: "Switch on type discriminator may indicate LSP violation. " +
                                 "Consider polymorphic method.",
                    });
                }
            },
        };
    },
};

Build Detection Into Your Process

The most effective teams integrate LSP violation detection into their CI/CD pipelines. Add grep-based checks or custom lint rules that run on every PR. Even if they're warnings rather than errors, they create awareness and prompt discussions during code review.

The Path Forward — From Detection to Resolution

Finding type checks is only the first step. The real work is understanding why they exist and how to eliminate them through proper abstraction design.

The investigation process:

When you find a type check, don't immediately try to remove it. Instead:

Identify what varies by type — What specific behavior differs for each subtype?
Understand why it's external — Why is this behavior in client code rather than the types themselves?
Determine if it belongs in the abstraction — Should the base type define this operation?
Check for missing abstractions — Is there a different abstraction that would unify the behavior?

investigation-example
TypeScript
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
// FOUND: Type check in payment processing
function getProcessingFee(payment: Payment): Money {
    if (payment instanceof CreditCardPayment) {
        return payment.amount.multiply(0.029).add(Money.cents(30));
    } else if (payment instanceof PayPalPayment) {
        return payment.amount.multiply(0.034);
    } else if (payment instanceof CryptoPayment) {
        return Money.cents(0);  // No fee
    }
    throw new Error("Unknown payment type");
}
 
// INVESTIGATION:
// Q: What varies by type? → The fee calculation formula
// Q: Why is it external? → Someone thought "fee" wasn't a Payment responsibility
// Q: Should it be in abstraction? → Yes! Each payment knows its own fee structure
// Q: Missing abstraction? → Payment should have getProcessingFee() method
 
// RESOLUTION: Move fee calculation into the types
abstract class Payment {
    abstract getProcessingFee(): Money;
}
 
class CreditCardPayment extends Payment {
    getProcessingFee(): Money {
        return this.amount.multiply(0.029).add(Money.cents(30));
    }
}
 
class PayPalPayment extends Payment {
    getProcessingFee(): Money {
        return this.amount.multiply(0.034);
    }
}
 
class CryptoPayment extends Payment {
    getProcessingFee(): Money {
        return Money.cents(0);
    }
}
 
// Client code becomes:
function getProcessingFee(payment: Payment): Money {
    return payment.getProcessingFee();  // Polymorphism!
}

Common resolution patterns:

Type Check Elimination Patterns
Pattern	Approach	When to Use
Push method to base class	Add abstract method to parent, implement in each subtype	When each subtype has its own version of the behavior
Extract to interface	Create interface for the capability, implement where appropriate	When only some subtypes have the capability
Strategy injection	Move varying behavior into injected strategies	When behavior varies independently from type identity
Visitor pattern	Use double dispatch to external behavior	When behavior must be external AND new operations are frequent
Hierarchy restructure	Redesign the type hierarchy to eliminate partial implementations	When the hierarchy itself is wrong

Page Complete

You now understand type checking in client code as the primary symptom of LSP violations. You can recognize its various forms—from obvious instanceof chains to subtle capability flags—and understand why it creates significant architectural debt. The next page explores another critical symptom: unexpected exceptions from subclasses.

Summary: Type Checking as LSP Violation Detector

Key Takeaways

•Type checking in client code is the primary symptom of LSP violations — When you see instanceof, you've found evidence of broken polymorphism
•It manifests in many forms — From explicit instanceof to subtle capability flags, type discriminators, and duck typing checks
•It creates cascading costs — OCP violations, scattered knowledge, missing case bugs, and refactoring resistance all follow
•Not all type checking is wrong — Serialization, tooling, and boundary code legitimately need type awareness
•Detection should be systematic — Use grep patterns, static analysis, and custom lint rules to surface type checks
•Investigation before elimination — Understand why the check exists before attempting removal; fix the abstraction, not the symptom

Moving forward:

The next page examines a related symptom: unexpected exceptions from subclasses. When subtypes throw exceptions that clients don't expect, it's another form of behavioral non-substitutability that creates fragile systems and defensive code patterns.