Detecting And Fixing Lsp Violations - Learning Module

Loading content...

0/246

Partial Implementations — The Incomplete Contract Fulfillment

The Method That Does Nothing

You're debugging a mysterious issue in your notification system. Users report that some notifications never arrive. The code looks correct:

function notifyAll(users: User[], message: string): void {
    const notificationService = getNotificationService();
    for (const user of users) {
        notificationService.send(user, message);
        logger.log(`Sent notification to ${user.email}`);
    }
}

The logs show messages going out. No exceptions. The send() method is being called for every user. Yet certain users never receive notifications.

After hours of investigation, you discover the culprit: MockNotificationService—a test double that was accidentally deployed to production. Its send() method looks like this:

send(user: User, message: string): void {
    // Mock implementation - does nothing
}

The method signature matches. The types check out. No exceptions are thrown. But the behavioral contract—"sending actually delivers a notification"—is completely unfulfilled. This is a partial implementation, and it's one of the most insidious forms of LSP violation.

What You Will Learn

By the end of this page, you will understand partial implementations as LSP violations, recognize the various forms they take (no-ops, stubs, default returns), understand why they're harder to detect than exception-throwing violations, and learn design strategies that prevent partial implementations from entering your codebase.

What Is a Partial Implementation?

A partial implementation is a subclass that provides method implementations which are syntactically correct but semantically incomplete. The methods exist, they can be called, they don't throw exceptions—but they don't actually fulfill the behavioral contract the base class establishes.

Forms of Partial Implementation

•No-op methods — Methods with empty bodies that do nothing: save(): void { }
•Stub returns — Methods returning hardcoded default values: calculate(): number { return 0; }
•Silent failures — Methods that detect failure conditions but swallow them silently
•Placeholder implementations — Methods marked with TODO that never get completed
•Degraded functionality — Methods that work but skip critical steps the contract implies
•Optional behavior omission — Methods that ignore optional aspects that clients depend on

partial-implementation-types
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
59
60
61
// TYPE 1: No-op methods
class NullLogger implements Logger {
    log(message: string): void {
        // Does nothing - but callers expect logging to occur
    }
    
    error(message: string, error: Error): void {
        // Also does nothing - errors are silently swallowed
    }
}
 
// TYPE 2: Stub returns
class FakeAuthService implements AuthService {
    authenticate(credentials: Credentials): User | null {
        // Always returns null - never actually authenticates
        return null;
    }
    
    isAuthenticated(): boolean {
        // Always returns false - never tracks auth state
        return false;
    }
}
 
// TYPE 3: Silent failures
class BestEffortCache implements Cache<string, any> {
    get(key: string): any | undefined {
        try {
            return this.internalGet(key);
        } catch {
            // Silently swallows errors - contract implies throwing on failure
            return undefined;
        }
    }
    
    set(key: string, value: any): void {
        try {
            this.internalSet(key, value);
        } catch {
            // Silently fails - caller thinks value is cached
        }
    }
}
 
// TYPE 4: Degraded functionality
class QuickDataProcessor implements DataProcessor {
    process(data: RawData): ProcessedData {
        // Contract implies validation, transformation, and enrichment
        // This implementation skips validation and enrichment
        return this.transformOnly(data);  // Partial fulfillment
    }
}
 
// TYPE 5: Optional behavior omission
class SimpleRepository implements Repository<Entity> {
    save(entity: Entity): void {
        this.database.insert(entity);
        // Contract implies firing events, updating audit log
        // This implementation omits those
    }
}

The deceptive nature of partial implementations:

Unlike exception-throwing violations (which at least fail explicitly), partial implementations appear to work. They compile. They run. They don't crash. Client code continues executing without any indication that something is wrong.

This makes them far more dangerous than explicit failures. The system operates in a degraded state—missing logs, lost data, incomplete processing—without any alarms firing.

The Silent Corruption Problem

Partial implementations cause silent corruption. Data is lost without errors. Logs that should exist don't. Invariants that should hold don't. The system appears healthy while accumulating invisible damage. By the time problems surface, the root cause is often far removed from the symptom.

Why Partial Implementations Occur

Partial implementations don't emerge from malice—they emerge from design pressures that push developers toward incomplete solutions. Understanding these pressures helps prevent them.

Common Causes of Partial Implementations
Cause	How It Leads to Partial Implementation	Example
Interface too large	Subclass can only meaningfully implement some methods	A `FileSystem` interface with sync and async methods, where some implementations only support one
Test doubles in wrong context	Mock/stub objects designed for testing used in production	MockPaymentGateway deployed accidentally
Gradual feature development	Methods added as stubs with intent to 'finish later'	`// TODO: implement caching` that stays forever
Different capability profiles	Subclasses genuinely can't do everything the parent can	A `PrintableDocument` where `EncryptedDocument` can print only under certain conditions
Decorator/Wrapper patterns misuse	Wrapper doesn't forward all behavior correctly	`CachingRepository.save()` caches but doesn't trigger events
Copy-paste inheritance	Copy a class, remove the parts you don't need, provide stubs	Copying `FullReportGenerator` to make `SummaryReportGenerator`

causes-in-code
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
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
// CAUSE 1: Interface too large
interface DataStore {
    get(key: string): Promise<any>;
    set(key: string, value: any): Promise<void>;
    delete(key: string): Promise<void>;
    list(): Promise<string[]>;
    watch(key: string, callback: (value: any) => void): void;
    transaction<T>(fn: (tx: Transaction) => T): Promise<T>;
    backup(): Promise<Blob>;
    restore(backup: Blob): Promise<void>;
}
 
// Some implementations can't do everything
class SimpleMemoryStore implements DataStore {
    get(key: string): Promise<any> { /* works */ }
    set(key: string, value: any): Promise<void> { /* works */ }
    delete(key: string): Promise<void> { /* works */ }
    list(): Promise<string[]> { /* works */ }
    watch(key: string, callback: (value: any) => void): void {
        // Stub - can't implement reactive watching in simple memory store
    }
    transaction<T>(fn: (tx: Transaction) => T): Promise<T> {
        // Stub - no real transaction support
        return fn(null as any);
    }
    backup(): Promise<Blob> {
        // Stub - returns empty blob
        return Promise.resolve(new Blob());
    }
    restore(backup: Blob): Promise<void> {
        // Stub - does nothing
        return Promise.resolve();
    }
}
 
 
// CAUSE 2: Decorator that doesn't forward correctly
class CachingUserRepository implements UserRepository {
    constructor(private inner: UserRepository, private cache: Cache) {}
    
    async find(id: string): Promise<User> {
        const cached = this.cache.get(id);
        if (cached) return cached;
        const user = await this.inner.find(id);
        this.cache.set(id, user);
        return user;
    }
    
    async save(user: User): Promise<void> {
        await this.inner.save(user);
        this.cache.set(user.id, user);
        // MISSING: inner.save() fires domain events
        // This decorator swallows them by not forwarding
    }
    
    async findByEmail(email: string): Promise<User | null> {
        // PARTIAL: Only caches by ID, not email
        // Repeated email lookups hit database every time
        return this.inner.findByEmail(email);
    }
}
 
 
// CAUSE 3: Test double used in production
class TestPaymentProcessor implements PaymentProcessor {
    // Designed for unit tests - tracks calls but doesn't process
    private calls: Payment[] = [];
    
    process(payment: Payment): Receipt {
        this.calls.push(payment);
        // Returns fake receipt - no actual processing
        return new Receipt('fake-id', payment.amount, 'test');
    }
    
    refund(receiptId: string): RefundResult {
        // Always succeeds - because it's a test double
        return { success: true };
    }
    
    // Used in tests to verify behavior
    getCalls(): Payment[] { return this.calls; }
}
 
// Somewhere in configuration:
if (config.useMockPayments) {
    container.register(PaymentProcessor, TestPaymentProcessor);
    // If this flag is mistakenly true in production...
}

The Root Cause Pattern

Most partial implementations stem from a single root cause: the interface is defined without considering whether all implementations can fulfill it completely. The cure is to design interfaces around what implementations can actually do, not what would be theoretically useful.

The Consequences of Partial Implementations

Partial implementations create a spectrum of problems, from subtle behavioral inconsistencies to catastrophic data loss. The severity depends on which parts of the contract are unfulfilled.

Consequence Categories

•Data Loss — Save operations that don't persist, cache sets that don't store, logs that don't record
•State Inconsistency — Operations that should update multiple components only update some
•Silent Failures — Error paths that complete without signaling problems
•Feature Gaps — Functionality that works for some implementations but silently fails for others
•Debugging Nightmares — Problems with no obvious cause because the code 'works'
•Trust Erosion — Once found, developers stop trusting the abstraction entirely

consequence-examples
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
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
// CONSEQUENCE: Data Loss
class QuickExportService implements ExportService {
    exportToFile(data: Report, path: string): void {
        // Contract: Export data to file
        // Partial: Skips large reports "for performance"
        if (data.rows.length > 10000) {
            // Silently does nothing - data never exported
            return;
        }
        fs.writeFileSync(path, serialize(data));
    }
}
 
// User exports a large report, thinks it's saved, deletes source data...
 
 
// CONSEQUENCE: State Inconsistency
class CachedOrderService implements OrderService {
    submitOrder(order: Order): OrderConfirmation {
        // Contract: Submit order, update inventory, notify warehouse
        const confirmation = this.orderRepository.save(order);
        this.cache.invalidate(order.customerId);  // Cache updated
        
        // PARTIAL: Inventory and warehouse notification not implemented yet
        // Inventory remains out of sync with actual orders
        
        return confirmation;
    }
}
 
 
// CONSEQUENCE: Silent Failures
class ResilientEmailSender implements EmailSender {
    send(email: Email): void {
        try {
            this.smtpClient.send(email);
        } catch (error) {
            // "Resilient" means swallowing all errors
            // Critical password reset emails silently fail
        }
    }
}
 
 
// CONSEQUENCE: Debugging Nightmare
async function processWorkflow(engine: WorkflowEngine): Promise<void> {
    await engine.startWorkflow('approval-flow', { documentId: 123 });
    // Workflow started successfully (according to the API)
    
    // Days later: "Why is this document not approved?"
    // Investigation reveals: TestWorkflowEngine was injected
    // startWorkflow() returns successfully but does nothing
}
 
 
// CONSEQUENCE: Trust Erosion (the meta-consequence)
class DefensiveOrderProcessor {
    async process(cart: ShoppingCart): Promise<void> {
        // Developer has been burned by partial implementations
        // Now adds verification everywhere
        
        const order = await this.orderService.create(cart);
        
        // Don't trust that create() actually created it
        const verified = await this.orderService.find(order.id);
        if (!verified) {
            throw new Error("Order creation returned but didn't persist");
        }
        
        await this.inventoryService.reserve(order.items);
        
        // Don't trust that reserve() actually reserved
        for (const item of order.items) {
            const stock = await this.inventoryService.getStock(item.sku);
            if (stock.reserved < item.quantity) {
                throw new Error("Reservation returned but didn't reserve");
            }
        }
        
        // The entire codebase becomes verification-heavy
        // All because abstractions can't be trusted
    }
}

The Verification Spiral

Once partial implementations erode trust, developers add verification code everywhere. This verification code adds latency, complexity, and its own bugs. The system becomes slower and more fragile, not from the original violation, but from the defensive response to it.

Detecting Partial Implementations

Unlike exception-throwing violations, partial implementations don't announce themselves. Detection requires proactive techniques that go beyond static analysis.

Detection Strategies

•Empty method body search — Find methods with empty bodies or single-line return statements
•TODO/FIXME mining — Search for incomplete implementation markers that were never addressed
•Coverage analysis per implementation — Compare code coverage across different implementations of the same interface
•Contract testing — Write tests that verify behavioral contracts, not just method existence
•Mutation testing — Partial implementations often have 100% coverage but low mutation scores
•Runtime behavior monitoring — Track actual effects (DB writes, API calls) per implementation type

detection-techniques
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# Find empty method bodies
# TypeScript/JavaScript - methods that just return or are empty
grep -rPn "\{\s*\}|\{\s*return;?\s*\}|\{\s*return \w+;\s*\}" --include="*.ts" src/
 
# Find TODO markers in method bodies
grep -rn "TODO\|FIXME\|HACK\|XXX" --include="*.ts" src/ | grep -v test
 
# Find methods returning default values
grep -rPn "return null;|return \[\];|return \{\};|return 0;|return '';|return false;" --include="*.ts" src/
 
# Find empty catch blocks (silent failures)
grep -rPn "catch.*\{\s*\}" --include="*.ts" src/
 
# Python equivalents
grep -rn "pass$\|return None$\|return \[\]$" --include="*.py" src/

Weak Detection

•Type checking only
•Method existence verification
•Return type validation
•Exception-only tests
•Happy path coverage

Strong Detection

•Behavioral contract tests
•Effect verification
•Cross-implementation consistency
•Mutation testing
•Runtime monitoring

The Observation Principle

For every method in your contract, ask: 'How would I observe that this method actually did its job?' If you can't observe any effect, you can't verify the contract. Design interfaces so that fulfillment is observable—through return values, side effects queries, or events.

Preventing Partial Implementations

Prevention is far cheaper than detection and remediation. These design strategies minimize the risk of partial implementations emerging in your codebase.

Prevention Strategies

•Minimal interfaces — Define interfaces with only the operations all implementations can genuinely provide
•Capability-based design — Split interfaces by capability, let types implement what they can
•Result types for fallible operations — Return Result<T> instead of throwing or silently failing
•Strong separation of test doubles — Test implementations never share type hierarchies with production code
•Decorator verification — Ensure decorators forward all behavior, not just some
•Interface design reviews — Review interface definitions before implementations begin

prevention-patterns
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
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
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
// STRATEGY 1: Minimal Interfaces
 
// BAD: Large interface forces partial implementations
interface DataStore {
    get(key: string): Promise<any>;
    set(key: string, value: any): Promise<void>;
    delete(key: string): Promise<void>;
    list(): Promise<string[]>;
    watch(key: string, callback: Callback): Subscription;
    transaction<T>(fn: (tx: Transaction) => T): Promise<T>;
    backup(): Promise<Blob>;
    restore(backup: Blob): Promise<void>;
}
 
// GOOD: Split into minimal capability interfaces
interface KeyValueStore {
    get(key: string): Promise<any | undefined>;
    set(key: string, value: any): Promise<void>;
    delete(key: string): Promise<void>;
}
 
interface ListableStore {
    list(prefix?: string): Promise<string[]>;
}
 
interface WatchableStore {
    watch(key: string, callback: Callback): Subscription;
}
 
interface TransactionalStore {
    transaction<T>(fn: (tx: Transaction) => T): Promise<T>;
}
 
interface BackupableStore {
    backup(): Promise<Blob>;
    restore(backup: Blob): Promise<void>;
}
 
// Implementations declare exactly what they support
class SimpleMemoryStore implements KeyValueStore, ListableStore {
    // Only implements what it can fully support
}
 
class RedisStore implements KeyValueStore, ListableStore, WatchableStore, TransactionalStore {
    // Implements everything it truly supports
}
 
 
// STRATEGY 2: Strong Test Double Separation
 
// BAD: Test double shares production interface
class MockEmailSender implements EmailSender {
    send(email: Email): void {
        // Does nothing - partial implementation
    }
}
 
// GOOD: Test infrastructure is completely separate
interface EmailSenderSpy {
    readonly sentEmails: Email[];
    readonly sendCalled: boolean;
    simulateFailure(error: Error): void;
}
 
// Factory creates test-specific implementations
function createEmailSenderForTesting(): EmailSender & EmailSenderSpy {
    const sent: Email[] = [];
    let failWith: Error | null = null;
    
    return {
        get sentEmails() { return sent; },
        get sendCalled() { return sent.length > 0; },
        simulateFailure(error) { failWith = error; },
        
        send(email) {
            if (failWith) throw failWith;
            sent.push(email);  // Actually tracks behavior
        }
    };
}
 
// Test code explicitly uses test type
const testSender = createEmailSenderForTesting();
// TypeScript won't let you use this where production EmailSender is needed
// (unless you explicitly cast, which is a code smell)
 
 
// STRATEGY 3: Result Types for Fallible Operations
 
// BAD: Silent failure possible
interface NotificationSender {
    send(notification: Notification): void;
}
 
// GOOD: Failure is part of the return type
interface NotificationSender {
    send(notification: Notification): SendResult;
}
 
type SendResult = 
    | { success: true; messageId: string }
    | { success: false; error: NotificationError };
 
// Implementations MUST return a result, can't silently fail
class EmailNotificationSender implements NotificationSender {
    send(notification: Notification): SendResult {
        try {
            const id = this.smtp.send(notification);
            return { success: true, messageId: id };
        } catch (error) {
            // CANNOT silently swallow - must return failure
            return { success: false, error: new NotificationError(error) };
        }
    }
}
 
 
// STRATEGY 4: Decorator Verification
 
// Helper that ensures decorators forward all behavior
function createVerifiedDecorator<T>(
    inner: T,
    wrapper: T,
    methodsToVerify: (keyof T)[]
): T {
    return new Proxy(wrapper, {
        get(target, prop) {
            const key = prop as keyof T;
            
            // Verify method exists on both
            if (methodsToVerify.includes(key)) {
                if (!(key in inner)) {
                    throw new Error(`Decorator missing forwarding for ${String(key)}`);
                }
            }
            
            return target[key];
        }
    });
}

The Least Capability Principle

Design interfaces around the least capable implementation you need to support. If one implementation can't do transactions, don't put transactions in the base interface. If one implementation can't watch for changes, create a separate WatchableStore interface. This prevents forcing any implementation into partial compliance.

Remediation Strategies

When you've identified partial implementations in an existing codebase, systematic remediation restores LSP compliance without breaking the system.

Remediation Approaches

•Complete the implementation — If the partial implementation was a TODO, finish it
•Split the interface — If some implementations can't fulfill some methods, separate those methods into capability interfaces
•Remove the implementation — If the type truly can't do what the interface requires, it shouldn't implement it
•Change the contract — If all implementations share the partial behavior, maybe the contract was wrong
•Add explicit capability queries — If variation is necessary, make it explicit with supports*() methods and documentation

remediation-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
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
// BEFORE: Partial implementation problem
interface ReportGenerator {
    generatePdf(data: ReportData): Buffer;
    generateExcel(data: ReportData): Buffer;
    generateCsv(data: ReportData): string;
    generateHtml(data: ReportData): string;
}
 
// SimpleReportGenerator can't do Excel
class SimpleReportGenerator implements ReportGenerator {
    generatePdf(data: ReportData): Buffer { /* works */ }
    generateExcel(data: ReportData): Buffer {
        return Buffer.alloc(0);  // PARTIAL: Returns empty buffer
    }
    generateCsv(data: ReportData): string { /* works */ }
    generateHtml(data: ReportData): string { /* works */ }
}
 
 
// REMEDIATION OPTION 1: Split the interface
interface BaseReportGenerator {
    generatePdf(data: ReportData): Buffer;
    generateCsv(data: ReportData): string;
    generateHtml(data: ReportData): string;
}
 
interface ExcelCapableGenerator extends BaseReportGenerator {
    generateExcel(data: ReportData): Buffer;
}
 
class SimpleReportGenerator implements BaseReportGenerator {
    // Now only claims what it can do
}
 
class FullReportGenerator implements ExcelCapableGenerator {
    // Implements everything including Excel
}
 
 
// REMEDIATION OPTION 2: Complete the implementation
class SimpleReportGenerator implements ReportGenerator {
    private excelLib = new ExcelLibrary();
    
    generateExcel(data: ReportData): Buffer {
        // Actually implement Excel generation
        return this.excelLib.generate(data);
    }
}
 
 
// REMEDIATION OPTION 3: Change to result-based contract
interface ReportGenerator {
    generate(data: ReportData, format: ReportFormat): GenerateResult;
    getSupportedFormats(): ReportFormat[];
}
 
type GenerateResult = 
    | { success: true; content: Buffer | string }
    | { success: false; error: 'unsupported' | 'generation_failed' };
 
class SimpleReportGenerator implements ReportGenerator {
    getSupportedFormats(): ReportFormat[] {
        return ['pdf', 'csv', 'html'];  // Explicitly no Excel
    }
    
    generate(data: ReportData, format: ReportFormat): GenerateResult {
        if (!this.getSupportedFormats().includes(format)) {
            return { success: false, error: 'unsupported' };
        }
        // ... generate supported format
    }
}
 
// Clients check support before calling, or handle result gracefully

Page Complete

You now understand partial implementations as a subtle but dangerous form of LSP violation. You can detect them through contract testing and behavioral verification, prevent them through minimal interface design, and remediate them through interface splitting or implementation completion. The next page covers systematic refactoring strategies for fixing LSP violations.

Summary: The Danger of Silent Compliance

Key Takeaways

•Partial implementations appear to work but don't fulfill contracts — No-ops, stubs, and silent failures violate LSP without throwing exceptions
•They're harder to detect than explicit failures — The system runs, tests pass, but behavior is incomplete
•Silent corruption is the primary consequence — Data loss, state inconsistency, and missing functionality accumulate invisibly
•Detection requires behavioral testing — Verify effects, not just method existence; use contract tests and mutation testing
•Prevention through minimal interfaces — Design interfaces around the least capable implementation; split capabilities
•Remediation through completion or splitting — Either finish the implementation or restructure the type hierarchy

Next up:

The final page of this module presents systematic refactoring strategies for LSP—patterns and techniques for transforming LSP-violating code into properly substitutable hierarchies while maintaining system stability throughout the refactoring process.