Weakening vs Strengthening — The… — Preconditions and… | OneNoughtOne

0/86

System Design (LLD)Liskov Substitution Principle

Preconditions and Postconditions

LevelIntermediate

Duration60 mins

TopicLiskov Substitution Principle

3 / 4

Weakening vs Strengthening — The Intuitive Guide

The Counterintuitive Logic of Contracts

We've established two rules: Preconditions may be weakened, never strengthened Postconditions may be strengthened, never weakened Many developers find this confusing at first. "Weaken" sounds negative, but weakening preconditions is good? "Strengthen" sounds positive, but strengthening preconditions is bad? The terminology becomes intuitive once you understand the underlying logic. This page consolidates and deepens your understanding of weakening and strengthening. We'll build mental models, work through edge cases, and develop a reliable intuition for analyzing any contract modification.

Learning Objectives

By the end of this page, you will: • Develop a reliable intuition for when modifications are safe • Understand the logic implication interpretation of weakening/strengthening • Master the "client perspective" mental model for LSP analysis • Recognize and resolve subtle edge cases in contract modification • Apply formal reasoning to any contract change scenario

The Language of Weakening and Strengthening

First, let's precisely define what "weaker" and "stronger" mean in contract terms. In logic, we say proposition A is stronger than B if: A implies B (A \to B) Whenever A is true, B is also true A is more specific, more restrictive, harder to satisfy Conversely, A is weaker than B if: B implies A (B \to A) A is more general, less restrictive, easier to satisfy Let's see concrete examples:

Strength Relationships Between Conditions
Stronger Condition	Weaker Condition	Why?
`x > 0`	`x >= 0`	Positive is a subset of non-negative
`x > 10`	`x > 0`	x > 10 implies x > 0, but not vice versa
`x == 5`	`x >= 0 && x <= 10`	Exactly 5 is more restrictive than 0-10 range
`list is sorted`	`list exists`	Sorted lists are a subset of all lists
`user is admin`	`user is authenticated`	Admins are authenticated, not all authenticated are admins
`false`	`true`	False is never satisfied; true always is

The key insight: A stronger condition is harder to satisfy because it imposes more requirements. A weaker condition is easier to satisfy because it accepts more cases. Think of conditions as filters: Stronger filter = Fewer things pass through Weaker filter = More things pass through

The 'Subset' Mental Model

A stronger condition describes a smaller set of possibilities. A weaker condition describes a larger set of possibilities. If set A \subset set B (A is a subset of B), then: Condition "x \in A" is STRONGER than "x \in B" Because everything in A is in B, but not everything in B is in A

Why the Rules Are Opposite

Now let's understand why preconditions and postconditions have opposite rules. It comes down to who is responsible and who relies on what .

Converting Mermaid diagram...

Preconditions (Caller \to Method): The caller must satisfy preconditions. The caller is written to the parent's precondition. If the subclass has a stronger precondition (harder to satisfy), the caller might not meet it — breakage! If the subclass has a weaker precondition (easier to satisfy), the caller definitely meets it. Whatever satisfies P_parent will also satisfy anything weaker. Postconditions (Method \to Caller): The caller relies on postconditions. The caller is written to handle the parent's postcondition. If the subclass has a weaker postcondition (promises less), the caller might get something it doesn't know how to handle — breakage! If the subclass has a stronger postcondition (promises more), the caller can definitely handle it. Whatever handles Q_parent can handle anything that implies Q_parent.

Precondition Logic

•Caller provides input satisfying P_parent
•If P_child is weaker: P_parent → P_child ✓
•Caller's valid input is still valid
•If P_child is stronger: P_parent ↛ P_child
•Caller's valid input might be invalid!

Postcondition Logic

•Caller expects output satisfying Q_parent
•If Q_child is stronger: Q_child → Q_parent ✓
•Child's output satisfies parent expectation
•If Q_child is weaker: Q_child ↛ Q_parent
•Child might produce unexpected outcomes!

The Direction of Implication

The formal rules: • Preconditions : P_parent \to P_child (parent implies child) • Postconditions : Q_child \to Q_parent (child implies parent) Parent precondition must imply child precondition (child accepts at least what parent accepts). Child postcondition must imply parent postcondition (child delivers at least what parent promises).

The Client Perspective Model

The most reliable way to analyze contract changes is to think from the client's perspective . The client is written against the parent's contract. What happens when the subclass is substituted? Let's develop a concrete mental model:

ClientPerspectiveModel
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
// ═══════════════════════════════════════════════════════════════
// PARENT CONTRACT
// ═══════════════════════════════════════════════════════════════
 
abstract class DataProcessor {
    /**
     * @precondition data.length >= 1
     * @postcondition returns number in range [0, 100]
     */
    abstract process(data: number[]): number;
}
 
// ═══════════════════════════════════════════════════════════════
// CLIENT CODE (written to parent contract)
// ═══════════════════════════════════════════════════════════════
 
function analyzeData(processor: DataProcessor, dataset: number[][]): void {
    for (const data of dataset) {
        // Client ENSURES: data.length >= 1 (satisfies precondition)
        if (data.length < 1) continue;  // Skip empty arrays
        
        const result = processor.process(data);
        
        // Client EXPECTS: result in [0, 100] (relies on postcondition)
        const percentage = result / 100;  // Safe division
        const category = getCategory(result);  // Assumes 0-100 range
        
        displayResult(percentage, category);
    }
}
 
function getCategory(score: number): string {
    // Written assuming score in [0, 100]
    if (score < 50) return "Low";
    if (score < 75) return "Medium";
    return "High";  // 75-100
}
 
// ═══════════════════════════════════════════════════════════════
// NOW: Analyze different subclass modifications
// ═══════════════════════════════════════════════════════════════

SafePrecondition
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class FlexibleProcessor extends DataProcessor {
    /**
     * @precondition data.length >= 0  // WEAKER (accepts empty!)
     * @postcondition returns number in range [0, 100]
     */
    process(data: number[]): number {
        if (data.length === 0) return 0;  // Handles empty case
        return this.compute(data);
    }
}
 
// CLIENT ANALYSIS:
// 
// Client sends: data.length >= 1 (always)
// Subclass accepts: data.length >= 0 (always)
// 
// Since 1 >= 1 implies 1 >= 0, client's input is ALWAYS valid.
// ✅ SAFE: Client can use this subclass.

The Client Test

For any contract change, ask: "Would client code written for the parent work with the child?" "Could the client ever provide input the child rejects?" "Could the child ever produce output the client doesn't expect?" If answers are Yes, Yes, No and No respectively — the change is safe.

Edge Cases and Subtleties

The basic rules are simple, but real-world cases can be subtle. Let's explore tricky scenarios:

EdgeCases
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
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
// ═══════════════════════════════════════════════════════════════
// EDGE CASE 1: Exception vs. Return Value
// ═══════════════════════════════════════════════════════════════
 
class Parser {
    /**
     * @postcondition returns AST if valid, null if invalid
     */
    parse(code: string): AST | null {
        try {
            return this.doParse(code);
        } catch {
            return null;
        }
    }
}
 
// Is this a violation?
class StrictParser extends Parser {
    /**
     * @postcondition returns AST if valid, throws if invalid
     */
    parse(code: string): AST {
        const result = super.parse(code);
        if (result === null) {
            throw new ParseError("Invalid syntax");
        }
        return result;
    }
}
 
// ANALYSIS: This is SUBTLE.
// 
// Return type changed from "AST | null" to "AST".
// On success: Same behavior (returns AST)
// On failure: Instead of returning, it throws
//
// This IS a weakening because the original postcondition said
// "returns null if invalid." Not returning is different from
// returning null. Client code doing:
//
//     const ast = parser.parse(code);
//     if (ast === null) { handleError(); }
//
// Will never reach handleError() — exception bypasses it.
//
// ⚠️ VERDICT: VIOLATION (though often acceptable in practice)
 
// ═══════════════════════════════════════════════════════════════
// EDGE CASE 2: Narrowing Type vs. Strengthening
// ═══════════════════════════════════════════════════════════════
 
class Container {
    /**
     * @postcondition returns the stored value
     */
    getValue(): object {
        return this.value;
    }
}
 
class TypedContainer extends Container {
    /**
     * @postcondition returns the stored value as User
     */
    getValue(): User {  // User extends object
        return this.value as User;
    }
}
 
// ANALYSIS: Return type is more specific.
// 
// User ⊂ object (User is a subset of object)
// So "returns User" → "returns object" (valid implication)
//
// ✅ VERDICT: SAFE strengthening
 
// ═══════════════════════════════════════════════════════════════
// EDGE CASE 3: Widening Type vs. Weakening Precondition
// ═══════════════════════════════════════════════════════════════
 
class StringProcessor {
    /**
     * @precondition input is non-null string
     */
    process(input: string): Result {
        return this.doProcess(input);
    }
}
 
class FlexibleProcessor extends StringProcessor {
    /**
     * @precondition input is string or null
     */
    process(input: string | null): Result {
        if (input === null) {
            return Result.empty();
        }
        return super.process(input);
    }
}
 
// ANALYSIS: Input type is broader.
//
// "non-null string" is a subset of "string or null"
// Parent's valid inputs are still valid for child.
//
// ✅ VERDICT: SAFE weakening of precondition
 
// ═══════════════════════════════════════════════════════════════
// EDGE CASE 4: The "Extra Functionality" Trap
// ═══════════════════════════════════════════════════════════════
 
class Logger {
    /**
     * @postcondition message is written to log file
     */
    log(message: string): void {
        this.file.write(message);
    }
}
 
class MetricsLogger extends Logger {
    /**
     * @postcondition message is written to log file
     * @postcondition metrics are updated (NEW SIDE EFFECT)
     */
    log(message: string): void {
        super.log(message);
        this.metrics.increment("log_count");
    }
}
 
// ANALYSIS: Extra postcondition added.
//
// Original: message written
// New: message written AND metrics updated
//
// "A AND B" → "A" (if both are true, A is true)
// Stronger postcondition (more guaranteed).
//
// ✅ VERDICT: SAFE strengthening
// (Client expects logs, gets logs + metrics — bonus!)
 
// ═══════════════════════════════════════════════════════════════
// EDGE CASE 5: The "Conditional Behavior" Trap
// ═══════════════════════════════════════════════════════════════
 
class Cache {
    /**
     * @postcondition returns cached value if present, null if not
     */
    get(key: string): T | null {
        return this.store.get(key) ?? null;
    }
}
 
class ExpiringCache extends Cache {
    /**
     * @postcondition returns cached value if present AND not expired
     * @postcondition returns null if not present OR expired
     */
    get(key: string): T | null {
        const entry = this.store.get(key);
        if (!entry) return null;
        if (this.isExpired(entry)) {
            this.store.delete(key);  // Evict expired
            return null;  // Return null for expired
        }
        return entry.value;
    }
}
 
// ANALYSIS: This is SUBTLE.
//
// Original null postcondition: "null if not present"
// New null postcondition: "null if not present OR expired"
//
// The subclass returns null in MORE cases (also when expired).
// Client expecting a value (because it knows it put one in)
// might get null if the value expired.
//
// Is this weakening? Depends on interpretation:
// - If "present" means "was ever added", this is WEAKENING (violation)
// - If "present" means "currently valid entry", this is PRESERVING
//
// ⚠️ VERDICT: DEPENDS ON CONTRACT INTERPRETATION
// Best practice: Make the parent contract explicit about expiration

When Contracts Are Ambiguous

Many real-world contracts are underspecified. When analyzing inheritance: Interpret the parent's contract as the client would reasonably expect If the subclass behaves differently in ways clients might notice, it's likely a violation When in doubt, document the contract more precisely and consider if substitution would surprise callers

A Formal Reasoning Framework

For complex cases, it helps to have a systematic approach. Here's a framework for formally analyzing whether a contract change is safe:

Contract Change Analysis Framework

•Identify Parent Contract: Write out P_parent (precondition) and Q_parent (postcondition) explicitly
•Identify Child Contract: Write out P_child and Q_child explicitly
•Check Precondition Rule: Does P_parent → P_child hold? (Does parent precondition imply child precondition?)
•Check Postcondition Rule: Does Q_child → Q_parent hold? (Does child postcondition imply parent postcondition?)
•Verify with Examples: Test with boundary cases — inputs at the edge of parent's valid range, outputs at the edge of expected outcomes
•Consider Client Code: What would a reasonable client expect? Would substitution surprise them?

FormalAnalysisExample
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
// ═══════════════════════════════════════════════════════════════
// APPLYING THE FRAMEWORK
// ═══════════════════════════════════════════════════════════════
 
// PARENT CONTRACT
class SortingAlgorithm {
    /**
     * Sorts an array in ascending order.
     * 
     * P_parent: array is not null
     * Q_parent: returned array is sorted ascending
     *           returned array contains same elements as input
     */
    sort(array: number[]): number[] {
        return [...array].sort((a, b) => a - b);
    }
}
 
// PROPOSED CHILD
class OptimizedSort extends SortingAlgorithm {
    /**
     * P_child: array is not null AND length < 1_000_000
     * Q_child: returned array is sorted ascending
     *          returned array contains same elements as input
     */
    sort(array: number[]): number[] {
        if (array.length >= 1_000_000) {
            throw new Error("Array too large");
        }
        // Uses O(n log n) algorithm with O(n) memory
        return this.mergeSort(array);
    }
}
 
// ═══════════════════════════════════════════════════════════════
// STEP 1: Parent Contract
// ═══════════════════════════════════════════════════════════════
// P_parent: array != null
// Q_parent: sorted ascending ∧ same elements
 
// ═══════════════════════════════════════════════════════════════
// STEP 2: Child Contract
// ═══════════════════════════════════════════════════════════════
// P_child: array != null ∧ array.length < 1_000_000
// Q_child: sorted ascending ∧ same elements
 
// ═══════════════════════════════════════════════════════════════
// STEP 3: Check Precondition Rule (P_parent → P_child?)
// ═══════════════════════════════════════════════════════════════
// Does (array != null) → (array != null ∧ length < 1M)?
// 
// NO! An array that is not null might have length >= 1M.
// The implication doesn't hold.
// 
// ❌ PRECONDITION VIOLATION
 
// ═══════════════════════════════════════════════════════════════
// STEP 4: Check Postcondition Rule (Q_child → Q_parent?)
// ═══════════════════════════════════════════════════════════════
// Does (sorted ∧ same elements) → (sorted ∧ same elements)?
//
// YES! Identical postconditions, so trivially true.
//
// ✅ POSTCONDITION OK
 
// ═══════════════════════════════════════════════════════════════
// STEP 5: Boundary Examples
// ═══════════════════════════════════════════════════════════════
// Client code might sort an array of 2,000,000 elements.
// Parent: Works fine
// Child: Throws exception!
 
// ═══════════════════════════════════════════════════════════════
// STEP 6: Client Perspective
// ═══════════════════════════════════════════════════════════════
// A client using SortingAlgorithm for large datasets would break.
// The child rejects inputs the parent accepts.
 
// ═══════════════════════════════════════════════════════════════
// CONCLUSION: OptimizedSort VIOLATES LSP
// ═══════════════════════════════════════════════════════════════
// To fix: Make large arrays a capability of the BASE class
// or use composition instead of inheritance.

The Invariant Connection

Before we summarize, let's briefly connect to invariants — the third element of Design by Contract that we'll cover fully in the next page. Invariants are conditions that must be true at all times (or at least, at all observable moments). They bridge preconditions and postconditions:

The Three Elements of a Contract
Element	When It Applies	LSP Rule	Example
Precondition	At method start	May weaken	`age > 0`
Postcondition	At method end	May strengthen	`name is non-empty after save`
Invariant	Always (entry/exit of any public method)	May strengthen	`balance >= 0 always`

Invariants are postconditions that apply to every method — conditions that are maintained across the object's lifetime. Like postconditions, subclasses may only strengthen invariants, never weaken them . If a parent class guarantees balance >= 0, a subclass can guarantee balance >= 100 (stronger), but never balance can be negative (weaker).

Preview: Invariants

The next page explores invariants in detail: what they are, how they differ from postconditions, and how to reason about them in inheritance hierarchies. For now, know that they follow the same "strengthening only" rule as postconditions.

Quick Reference: The Decision Tree

Here's a practical decision tree for analyzing contract modifications:

Converting Mermaid diagram...

Quick Rules

•Preconditions: "Child accepts more ? " → ✅ | "Child rejects some ? " → ❌
•Postconditions: "Child promises more ? " → ✅ | "Child promises less ? " → ❌
•Invariants: "Child maintains stricter ? " → ✅ | "Child allows violations ? " → ❌

System Design (LLD)Liskov Substitution Principle

Preconditions and Postconditions

LevelIntermediate

Duration60 mins

TopicLiskov Substitution Principle

3 / 4

Weakening vs Strengthening — The Intuitive Guide

The Counterintuitive Logic of Contracts

We've established two rules: Preconditions may be weakened, never strengthened Postconditions may be strengthened, never weakened Many developers find this confusing at first. "Weaken" sounds negative, but weakening preconditions is good? "Strengthen" sounds positive, but strengthening preconditions is bad? The terminology becomes intuitive once you understand the underlying logic. This page consolidates and deepens your understanding of weakening and strengthening. We'll build mental models, work through edge cases, and develop a reliable intuition for analyzing any contract modification.

Learning Objectives

By the end of this page, you will: • Develop a reliable intuition for when modifications are safe • Understand the logic implication interpretation of weakening/strengthening • Master the "client perspective" mental model for LSP analysis • Recognize and resolve subtle edge cases in contract modification • Apply formal reasoning to any contract change scenario

The Language of Weakening and Strengthening

First, let's precisely define what "weaker" and "stronger" mean in contract terms. In logic, we say proposition A is stronger than B if: A implies B (A \to B) Whenever A is true, B is also true A is more specific, more restrictive, harder to satisfy Conversely, A is weaker than B if: B implies A (B \to A) A is more general, less restrictive, easier to satisfy Let's see concrete examples:

Strength Relationships Between Conditions
Stronger Condition	Weaker Condition	Why?
`x > 0`	`x >= 0`	Positive is a subset of non-negative
`x > 10`	`x > 0`	x > 10 implies x > 0, but not vice versa
`x == 5`	`x >= 0 && x <= 10`	Exactly 5 is more restrictive than 0-10 range
`list is sorted`	`list exists`	Sorted lists are a subset of all lists
`user is admin`	`user is authenticated`	Admins are authenticated, not all authenticated are admins
`false`	`true`	False is never satisfied; true always is

The key insight: A stronger condition is harder to satisfy because it imposes more requirements. A weaker condition is easier to satisfy because it accepts more cases. Think of conditions as filters: Stronger filter = Fewer things pass through Weaker filter = More things pass through

The 'Subset' Mental Model

A stronger condition describes a smaller set of possibilities. A weaker condition describes a larger set of possibilities. If set A \subset set B (A is a subset of B), then: Condition "x \in A" is STRONGER than "x \in B" Because everything in A is in B, but not everything in B is in A

Why the Rules Are Opposite

Now let's understand why preconditions and postconditions have opposite rules. It comes down to who is responsible and who relies on what .

Converting Mermaid diagram...

Preconditions (Caller \to Method): The caller must satisfy preconditions. The caller is written to the parent's precondition. If the subclass has a stronger precondition (harder to satisfy), the caller might not meet it — breakage! If the subclass has a weaker precondition (easier to satisfy), the caller definitely meets it. Whatever satisfies P_parent will also satisfy anything weaker. Postconditions (Method \to Caller): The caller relies on postconditions. The caller is written to handle the parent's postcondition. If the subclass has a weaker postcondition (promises less), the caller might get something it doesn't know how to handle — breakage! If the subclass has a stronger postcondition (promises more), the caller can definitely handle it. Whatever handles Q_parent can handle anything that implies Q_parent.

Precondition Logic

•Caller provides input satisfying P_parent
•If P_child is weaker: P_parent → P_child ✓
•Caller's valid input is still valid
•If P_child is stronger: P_parent ↛ P_child
•Caller's valid input might be invalid!

Postcondition Logic

•Caller expects output satisfying Q_parent
•If Q_child is stronger: Q_child → Q_parent ✓
•Child's output satisfies parent expectation
•If Q_child is weaker: Q_child ↛ Q_parent
•Child might produce unexpected outcomes!

The Direction of Implication

The formal rules: • Preconditions : P_parent \to P_child (parent implies child) • Postconditions : Q_child \to Q_parent (child implies parent) Parent precondition must imply child precondition (child accepts at least what parent accepts). Child postcondition must imply parent postcondition (child delivers at least what parent promises).

The Client Perspective Model

The most reliable way to analyze contract changes is to think from the client's perspective . The client is written against the parent's contract. What happens when the subclass is substituted? Let's develop a concrete mental model:

ClientPerspectiveModel
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
// ═══════════════════════════════════════════════════════════════
// PARENT CONTRACT
// ═══════════════════════════════════════════════════════════════
 
abstract class DataProcessor {
    /**
     * @precondition data.length >= 1
     * @postcondition returns number in range [0, 100]
     */
    abstract process(data: number[]): number;
}
 
// ═══════════════════════════════════════════════════════════════
// CLIENT CODE (written to parent contract)
// ═══════════════════════════════════════════════════════════════
 
function analyzeData(processor: DataProcessor, dataset: number[][]): void {
    for (const data of dataset) {
        // Client ENSURES: data.length >= 1 (satisfies precondition)
        if (data.length < 1) continue;  // Skip empty arrays
        
        const result = processor.process(data);
        
        // Client EXPECTS: result in [0, 100] (relies on postcondition)
        const percentage = result / 100;  // Safe division
        const category = getCategory(result);  // Assumes 0-100 range
        
        displayResult(percentage, category);
    }
}
 
function getCategory(score: number): string {
    // Written assuming score in [0, 100]
    if (score < 50) return "Low";
    if (score < 75) return "Medium";
    return "High";  // 75-100
}
 
// ═══════════════════════════════════════════════════════════════
// NOW: Analyze different subclass modifications
// ═══════════════════════════════════════════════════════════════

SafePrecondition
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class FlexibleProcessor extends DataProcessor {
    /**
     * @precondition data.length >= 0  // WEAKER (accepts empty!)
     * @postcondition returns number in range [0, 100]
     */
    process(data: number[]): number {
        if (data.length === 0) return 0;  // Handles empty case
        return this.compute(data);
    }
}
 
// CLIENT ANALYSIS:
// 
// Client sends: data.length >= 1 (always)
// Subclass accepts: data.length >= 0 (always)
// 
// Since 1 >= 1 implies 1 >= 0, client's input is ALWAYS valid.
// ✅ SAFE: Client can use this subclass.

The Client Test

For any contract change, ask: "Would client code written for the parent work with the child?" "Could the client ever provide input the child rejects?" "Could the child ever produce output the client doesn't expect?" If answers are Yes, Yes, No and No respectively — the change is safe.

Edge Cases and Subtleties

The basic rules are simple, but real-world cases can be subtle. Let's explore tricky scenarios:

EdgeCases
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
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
// ═══════════════════════════════════════════════════════════════
// EDGE CASE 1: Exception vs. Return Value
// ═══════════════════════════════════════════════════════════════
 
class Parser {
    /**
     * @postcondition returns AST if valid, null if invalid
     */
    parse(code: string): AST | null {
        try {
            return this.doParse(code);
        } catch {
            return null;
        }
    }
}
 
// Is this a violation?
class StrictParser extends Parser {
    /**
     * @postcondition returns AST if valid, throws if invalid
     */
    parse(code: string): AST {
        const result = super.parse(code);
        if (result === null) {
            throw new ParseError("Invalid syntax");
        }
        return result;
    }
}
 
// ANALYSIS: This is SUBTLE.
// 
// Return type changed from "AST | null" to "AST".
// On success: Same behavior (returns AST)
// On failure: Instead of returning, it throws
//
// This IS a weakening because the original postcondition said
// "returns null if invalid." Not returning is different from
// returning null. Client code doing:
//
//     const ast = parser.parse(code);
//     if (ast === null) { handleError(); }
//
// Will never reach handleError() — exception bypasses it.
//
// ⚠️ VERDICT: VIOLATION (though often acceptable in practice)
 
// ═══════════════════════════════════════════════════════════════
// EDGE CASE 2: Narrowing Type vs. Strengthening
// ═══════════════════════════════════════════════════════════════
 
class Container {
    /**
     * @postcondition returns the stored value
     */
    getValue(): object {
        return this.value;
    }
}
 
class TypedContainer extends Container {
    /**
     * @postcondition returns the stored value as User
     */
    getValue(): User {  // User extends object
        return this.value as User;
    }
}
 
// ANALYSIS: Return type is more specific.
// 
// User ⊂ object (User is a subset of object)
// So "returns User" → "returns object" (valid implication)
//
// ✅ VERDICT: SAFE strengthening
 
// ═══════════════════════════════════════════════════════════════
// EDGE CASE 3: Widening Type vs. Weakening Precondition
// ═══════════════════════════════════════════════════════════════
 
class StringProcessor {
    /**
     * @precondition input is non-null string
     */
    process(input: string): Result {
        return this.doProcess(input);
    }
}
 
class FlexibleProcessor extends StringProcessor {
    /**
     * @precondition input is string or null
     */
    process(input: string | null): Result {
        if (input === null) {
            return Result.empty();
        }
        return super.process(input);
    }
}
 
// ANALYSIS: Input type is broader.
//
// "non-null string" is a subset of "string or null"
// Parent's valid inputs are still valid for child.
//
// ✅ VERDICT: SAFE weakening of precondition
 
// ═══════════════════════════════════════════════════════════════
// EDGE CASE 4: The "Extra Functionality" Trap
// ═══════════════════════════════════════════════════════════════
 
class Logger {
    /**
     * @postcondition message is written to log file
     */
    log(message: string): void {
        this.file.write(message);
    }
}
 
class MetricsLogger extends Logger {
    /**
     * @postcondition message is written to log file
     * @postcondition metrics are updated (NEW SIDE EFFECT)
     */
    log(message: string): void {
        super.log(message);
        this.metrics.increment("log_count");
    }
}
 
// ANALYSIS: Extra postcondition added.
//
// Original: message written
// New: message written AND metrics updated
//
// "A AND B" → "A" (if both are true, A is true)
// Stronger postcondition (more guaranteed).
//
// ✅ VERDICT: SAFE strengthening
// (Client expects logs, gets logs + metrics — bonus!)
 
// ═══════════════════════════════════════════════════════════════
// EDGE CASE 5: The "Conditional Behavior" Trap
// ═══════════════════════════════════════════════════════════════
 
class Cache {
    /**
     * @postcondition returns cached value if present, null if not
     */
    get(key: string): T | null {
        return this.store.get(key) ?? null;
    }
}
 
class ExpiringCache extends Cache {
    /**
     * @postcondition returns cached value if present AND not expired
     * @postcondition returns null if not present OR expired
     */
    get(key: string): T | null {
        const entry = this.store.get(key);
        if (!entry) return null;
        if (this.isExpired(entry)) {
            this.store.delete(key);  // Evict expired
            return null;  // Return null for expired
        }
        return entry.value;
    }
}
 
// ANALYSIS: This is SUBTLE.
//
// Original null postcondition: "null if not present"
// New null postcondition: "null if not present OR expired"
//
// The subclass returns null in MORE cases (also when expired).
// Client expecting a value (because it knows it put one in)
// might get null if the value expired.
//
// Is this weakening? Depends on interpretation:
// - If "present" means "was ever added", this is WEAKENING (violation)
// - If "present" means "currently valid entry", this is PRESERVING
//
// ⚠️ VERDICT: DEPENDS ON CONTRACT INTERPRETATION
// Best practice: Make the parent contract explicit about expiration

When Contracts Are Ambiguous

Many real-world contracts are underspecified. When analyzing inheritance: Interpret the parent's contract as the client would reasonably expect If the subclass behaves differently in ways clients might notice, it's likely a violation When in doubt, document the contract more precisely and consider if substitution would surprise callers

A Formal Reasoning Framework

For complex cases, it helps to have a systematic approach. Here's a framework for formally analyzing whether a contract change is safe:

Contract Change Analysis Framework

•Identify Parent Contract: Write out P_parent (precondition) and Q_parent (postcondition) explicitly
•Identify Child Contract: Write out P_child and Q_child explicitly
•Check Precondition Rule: Does P_parent → P_child hold? (Does parent precondition imply child precondition?)
•Check Postcondition Rule: Does Q_child → Q_parent hold? (Does child postcondition imply parent postcondition?)
•Verify with Examples: Test with boundary cases — inputs at the edge of parent's valid range, outputs at the edge of expected outcomes
•Consider Client Code: What would a reasonable client expect? Would substitution surprise them?

FormalAnalysisExample
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
// ═══════════════════════════════════════════════════════════════
// APPLYING THE FRAMEWORK
// ═══════════════════════════════════════════════════════════════
 
// PARENT CONTRACT
class SortingAlgorithm {
    /**
     * Sorts an array in ascending order.
     * 
     * P_parent: array is not null
     * Q_parent: returned array is sorted ascending
     *           returned array contains same elements as input
     */
    sort(array: number[]): number[] {
        return [...array].sort((a, b) => a - b);
    }
}
 
// PROPOSED CHILD
class OptimizedSort extends SortingAlgorithm {
    /**
     * P_child: array is not null AND length < 1_000_000
     * Q_child: returned array is sorted ascending
     *          returned array contains same elements as input
     */
    sort(array: number[]): number[] {
        if (array.length >= 1_000_000) {
            throw new Error("Array too large");
        }
        // Uses O(n log n) algorithm with O(n) memory
        return this.mergeSort(array);
    }
}
 
// ═══════════════════════════════════════════════════════════════
// STEP 1: Parent Contract
// ═══════════════════════════════════════════════════════════════
// P_parent: array != null
// Q_parent: sorted ascending ∧ same elements
 
// ═══════════════════════════════════════════════════════════════
// STEP 2: Child Contract
// ═══════════════════════════════════════════════════════════════
// P_child: array != null ∧ array.length < 1_000_000
// Q_child: sorted ascending ∧ same elements
 
// ═══════════════════════════════════════════════════════════════
// STEP 3: Check Precondition Rule (P_parent → P_child?)
// ═══════════════════════════════════════════════════════════════
// Does (array != null) → (array != null ∧ length < 1M)?
// 
// NO! An array that is not null might have length >= 1M.
// The implication doesn't hold.
// 
// ❌ PRECONDITION VIOLATION
 
// ═══════════════════════════════════════════════════════════════
// STEP 4: Check Postcondition Rule (Q_child → Q_parent?)
// ═══════════════════════════════════════════════════════════════
// Does (sorted ∧ same elements) → (sorted ∧ same elements)?
//
// YES! Identical postconditions, so trivially true.
//
// ✅ POSTCONDITION OK
 
// ═══════════════════════════════════════════════════════════════
// STEP 5: Boundary Examples
// ═══════════════════════════════════════════════════════════════
// Client code might sort an array of 2,000,000 elements.
// Parent: Works fine
// Child: Throws exception!
 
// ═══════════════════════════════════════════════════════════════
// STEP 6: Client Perspective
// ═══════════════════════════════════════════════════════════════
// A client using SortingAlgorithm for large datasets would break.
// The child rejects inputs the parent accepts.
 
// ═══════════════════════════════════════════════════════════════
// CONCLUSION: OptimizedSort VIOLATES LSP
// ═══════════════════════════════════════════════════════════════
// To fix: Make large arrays a capability of the BASE class
// or use composition instead of inheritance.

The Invariant Connection

Before we summarize, let's briefly connect to invariants — the third element of Design by Contract that we'll cover fully in the next page. Invariants are conditions that must be true at all times (or at least, at all observable moments). They bridge preconditions and postconditions:

The Three Elements of a Contract
Element	When It Applies	LSP Rule	Example
Precondition	At method start	May weaken	`age > 0`
Postcondition	At method end	May strengthen	`name is non-empty after save`
Invariant	Always (entry/exit of any public method)	May strengthen	`balance >= 0 always`

Invariants are postconditions that apply to every method — conditions that are maintained across the object's lifetime. Like postconditions, subclasses may only strengthen invariants, never weaken them . If a parent class guarantees balance >= 0, a subclass can guarantee balance >= 100 (stronger), but never balance can be negative (weaker).

Preview: Invariants

The next page explores invariants in detail: what they are, how they differ from postconditions, and how to reason about them in inheritance hierarchies. For now, know that they follow the same "strengthening only" rule as postconditions.

Quick Reference: The Decision Tree

Here's a practical decision tree for analyzing contract modifications:

Converting Mermaid diagram...

Quick Rules

•Preconditions: "Child accepts more ? " → ✅ | "Child rejects some ? " → ❌
•Postconditions: "Child promises more ? " → ✅ | "Child promises less ? " → ❌
•Invariants: "Child maintains stricter ? " → ✅ | "Child allows violations ? " → ❌

Weakening vs Strengthening — The Intuitive Guide

The Counterintuitive Logic of Contracts

The Language of Weakening and Strengthening

Why the Rules Are Opposite

The Client Perspective Model

Edge Cases and Subtleties

A Formal Reasoning Framework

The Invariant Connection

Quick Reference: The Decision Tree

Quick Rules

There’s more to understand.

Weakening vs Strengthening — The Intuitive Guide

The Counterintuitive Logic of Contracts

The Language of Weakening and Strengthening

Why the Rules Are Opposite

The Client Perspective Model

Edge Cases and Subtleties

A Formal Reasoning Framework

The Invariant Connection

Quick Reference: The Decision Tree

Quick Rules

There’s more to understand.