Liskov Substitution Principle - Subtype Behavioural Contract

▶

Steps

setup

Define Base Class Shape

We define the abstract base class Shape with methods to set width and height and to calculate area. This sets the contract that all shapes must follow.

💡 Defining the base class establishes the expected interface and behavior that subtypes must honor.

Line:

class Shape:
    def set_width(self, width):
        pass
    def set_height(self, height):
        pass
    def area(self):
        pass

💡 The base class defines the behavioral contract for all shapes.

setup

Define Rectangle Subclass

We define Rectangle as a subclass of Shape, implementing width and height fields and overriding methods to set them and compute area.

💡 This subclass follows the base class contract by implementing all abstract methods.

Line:

class Rectangle(Shape):
    def __init__(self):
        self.width = 0
        self.height = 0
    def set_width(self, width):
        self.width = width
    def set_height(self, height):
        self.height = height
    def area(self):
        return self.width * self.height

💡 Rectangle correctly implements the base class contract.

setup

Define Square Subclass

We define Square as a subclass of Shape, but it overrides set_width and set_height to keep width and height equal, violating the expected behavior.

💡 This subclass breaks the behavioral contract by changing the meaning of setters.

Line:

class Square(Shape):
    def __init__(self):
        self.size = 0
    def set_width(self, width):
        self.size = width
    def set_height(self, height):
        self.size = height
    def area(self):
        return self.size * self.size

💡 Square violates the Liskov Substitution Principle by changing expected behavior.

fill_cells

Instantiate Rectangle and Set Dimensions

We create a Rectangle instance and set width to 5 and height to 10, following the expected behavior.

💡 This shows how a Rectangle behaves as expected when setting dimensions.

Line:

rect = Rectangle()
rect.set_width(5)
rect.set_height(10)

💡 Rectangle stores width and height independently as expected.

compare

Calculate Rectangle Area

We call the area method on the Rectangle instance, which multiplies width and height to return 50.

💡 This confirms Rectangle behaves as expected per the base contract.

Line:

area_rect = rect.area()

💡 Area calculation uses independent width and height fields.

fill_cells

Instantiate Square and Set Width

We create a Square instance and set width to 5. Internally, size is set to 5.

💡 Square uses a single size field, so setting width affects height implicitly.

Line:

sq = Square()
sq.set_width(5)

💡 Square's setters do not behave independently, violating expectations.

fill_cells

Set Square Height

We set the height of the Square to 10, which also sets size to 10, changing width implicitly.

💡 Square's setters affect the same size field, breaking independent dimension setting.

Line:

sq.set_height(10)

💡 Square cannot maintain independent width and height, violating the base contract.

compare

Calculate Square Area

We call area on the Square instance, which returns size * size = 100, inconsistent with expected independent width and height.

💡 Square's area calculation does not match expectations if treated as a Rectangle subtype.

Line:

area_sq = sq.area()

💡 Square's behavior breaks the base class contract, violating LSP.

compare

Substitute Rectangle with Square in Client Code

We substitute a Square instance where a Rectangle is expected and set width and height independently, expecting area to be width * height.

💡 This substitution reveals behavioral contract violation when Square is used as a Rectangle.

Line:

def use_shape(shape):
    shape.set_width(5)
    shape.set_height(10)
    return shape.area()

result = use_shape(sq)

💡 Square does not behave as a Rectangle, violating LSP.

compare

Observe Violation of Behavioral Contract

The area returned is 100 instead of expected 50, showing that Square does not honor the Rectangle contract, violating LSP.

💡 This final step reveals the practical impact of violating the behavioral contract.

Line:

print(result)  # Outputs 100, not 50 as expected

💡 Subtypes must preserve expected behavior to satisfy LSP.

class Shape:
    def set_width(self, width):  # STEP 1
        pass
    def set_height(self, height):  # STEP 1
        pass
    def area(self):  # STEP 1
        pass

class Rectangle(Shape):  # STEP 2
    def __init__(self):
        self.width = 0
        self.height = 0
    def set_width(self, width):  # STEP 2
        self.width = width
    def set_height(self, height):  # STEP 2
        self.height = height
    def area(self):  # STEP 5
        return self.width * self.height

class Square(Shape):  # STEP 3
    def __init__(self):
        self.size = 0
    def set_width(self, width):  # STEP 6
        self.size = width
    def set_height(self, height):  # STEP 7
        self.size = height
    def area(self):  # STEP 8
        return self.size * self.size

# Instantiate Rectangle and set dimensions  # STEP 4
rect = Rectangle()
rect.set_width(5)
rect.set_height(10)
area_rect = rect.area()  # STEP 5

# Instantiate Square and set dimensions  # STEP 6,7
sq = Square()
sq.set_width(5)
sq.set_height(10)
area_sq = sq.area()  # STEP 8

# Substitute Square where Rectangle expected  # STEP 9

def use_shape(shape):
    shape.set_width(5)
    shape.set_height(10)
    return shape.area()

result = use_shape(sq)  # STEP 9
print(result)  # STEP 10

📊

Liskov Substitution Principle - Subtype Behavioural Contract - Watch the Algorithm Execute, Step by Step

Watching this step-by-step helps you understand how subtype behavioral contracts ensure substitutability, which is hard to grasp from code alone.

Defines the abstract base class with the behavioral contract

«abstract»Shape

+set_width()

+set_height()

+area()

Rectangle implements the Shape contract

«abstract»Shape

+set_width()

+set_height()

+area()

Rectangle

−width: int

−height: int

+__init__()

+set_width()

+set_height()

+1 more

Rectangle ▷ Shape (1:1)

Square violates the behavioral contract by changing setter semantics

«abstract»Shape

+set_width()

+set_height()

+area()

Rectangle

−width: int

−height: int

+__init__()

+set_width()

+set_height()

+1 more

Square

−size: int

+__init__()

+set_width()

+set_height()

+1 more

Rectangle ▷ Shape (1:1)Square ▷ Shape (1:1)

⚠ Violates Liskov Substitution Principle: Square changes expected behavior of setters

Rectangle instance with width and height set independently

Rectangle

−width: int

−height: int

+set_width()

+set_height()

+area()

Rectangle ▷ Shape (1:1)

Rectangle area method returns width * height = 50

Rectangle

−width: int

−height: int

+area()

Rectangle ▷ Shape (1:1)

Square instance with size set to 5 via set_width

Square

−size: int

+set_width()

+set_height()

+area()

Square ▷ Shape (1:1)

Square size updated to 10 via set_height

Square

−size: int

+set_width()

+set_height()

+area()

Square ▷ Shape (1:1)

Square area method returns size * size = 100

Square

−size: int

+area()

Square ▷ Shape (1:1)

⚠ Violates LSP: area inconsistent with independent width and height

Square used polymorphically as Shape/Rectangle

«abstract»Shape

+set_width()

+set_height()

+area()

Square

−size: int

+set_width()

+set_height()

+area()

Square ▷ Shape (1:1)

⚠ Violates LSP: substitution breaks expected behavior

Final state shows behavioral contract violation

Square

−size: int

+area()

Square ▷ Shape (1:1)

⚠ LSP violation: Square does not behave as Rectangle

Key Takeaways

✓ Subtypes must preserve the behavioral contract of their base types to satisfy the Liskov Substitution Principle.

This is hard to see from code alone because method signatures may match but behavior can differ subtly.

✓ Violating the contract leads to unexpected results when subtypes are used polymorphically.

Visualizing the substitution and its effect on state and output clarifies why this is problematic.

✓ Designing subtypes requires careful attention to not only interface but also semantics and side effects.

The trace shows concretely how Square's setters break expectations, a subtle but critical insight.

Practice

1. You need to design a system where user actions can be executed, undone, and redone, while also supporting queuing of requests and logging of all operations. Which design approach best fits this requirement to ensure loose coupling between the invoker and the receiver and to enable undo/redo functionality?

easy

A. Implementing the Command Pattern where each action is encapsulated as an object with execute and undo methods, and the invoker manages undo and redo stacks.

B. Using a simple function call approach where each action directly modifies the receiver's state without encapsulation.

C. Applying a greedy algorithm that chooses the next best action to execute without storing history.

D. Using a dynamic programming approach to store all possible states and transitions for undo/redo.

Solution

1. Step 1: Identify the need for encapsulation of actions

   The problem requires actions to be undoable and redoable, which demands encapsulating each action's execution and reversal logic.

2. Step 2: Recognize the pattern that supports undo/redo and request queuing

   The Command Pattern encapsulates requests as objects, allowing the invoker to queue, log, and manage undo/redo stacks independently from the receiver.

3. Final Answer:

   Option A -> Option A

4. Quick Check:

   Command Pattern enables undo/redo with encapsulated commands [OK]

Hint: Undo/redo needs encapsulated commands, not direct calls [OK]

Common Mistakes:

• Thinking direct function calls can support undo/redo cleanly
• Confusing Command Pattern with greedy or DP algorithms

2. Given the following Python code using the Builder pattern, what is the output of print(house) after constructing a basic house with the Director?

easy

A. House parts: Walls, Roof

B. House parts: Walls, Roof, Pool

C. House parts: Roof, Walls

D. House parts: Pool

Solution

1. Step 1: Trace Director.construct_basic_house()

   The Director calls build_walls() and build_roof() on the builder, adding "Walls" and "Roof" to the house parts.

2. Step 2: Check the final house parts list

   The house parts list contains ["Walls", "Roof"]. The pool is not added in this method.

3. Final Answer:

   Option A -> Option A

4. Quick Check:

   Only walls and roof are added in basic house construction [OK]

Hint: Basic house adds walls and roof only [OK]

Common Mistakes:

• Assuming pool is added by default
• Mixing order of parts

3. When a new feature is added by extending a class hierarchy following the Open/Closed Principle, what is the typical sequence of events when the system executes a method call on the new subclass instance?

easy

A. The base class method is always executed first, then the subclass method overrides it afterward

B. The system duplicates the base class code inside the subclass to avoid modifying the base

C. The subclass method is invoked directly due to polymorphism, without modifying base class code

D. Both base and subclass methods execute sequentially because the base class is modified to call the subclass

Solution

1. Step 1: Understand polymorphic dispatch

   Method calls on subclass instances invoke the subclass's overridden method directly.

2. Step 2: Base class code remains unchanged

   The base class is closed for modification; no changes are made to call subclass methods explicitly.

3. Step 3: Why other options are incorrect

   The base class method is always executed first, then the subclass method overrides it afterward incorrectly suggests base method runs first then subclass; Both base and subclass methods execute sequentially because the base class is modified to call the subclass implies base class modification; The system duplicates the base class code inside the subclass to avoid modifying the base suggests code duplication, violating DRY and OCP.

4. Final Answer:

   Option C -> Option C

5. Quick Check:

   Polymorphism enables extension without modifying base code.

Hint: Polymorphism calls subclass methods directly [OK]

Common Mistakes:

• Assuming base method always runs first
• Believing base class must be modified to support extension
• Thinking code duplication is a valid OCP strategy

4. Imagine a class responsible for both data persistence and data validation. When a change in validation rules occurs, trace the impact on the class and explain what happens step-by-step.

easy

A. Only the validation methods need modification; persistence remains unaffected, so SRP is maintained.

B. Changing validation rules forces modifying the entire class, risking unintended side effects on persistence logic.

C. Validation changes automatically propagate to persistence without code changes due to tight coupling.

D. Persistence logic will break because validation and persistence are tightly integrated and inseparable.

Solution

1. Step 1: Identify responsibilities

   The class handles both validation and persistence, two distinct reasons to change.

2. Step 2: Trace change impact

   Changing validation rules requires modifying validation code inside the class.

3. Step 3: Side effects

   Because persistence logic shares the class, changes risk affecting persistence unintentionally, increasing maintenance risk.

4. Step 4: SRP violation

   This coupling violates SRP, as one reason to change (validation) affects unrelated functionality (persistence).

5. Final Answer:

   Option B -> Option B

6. Quick Check:

   One reason to change should not force changes in unrelated code -> SRP violation.

Hint: One reason to change means one place to modify.

Common Mistakes:

• Assuming changes affect only related methods without side effects.
• Believing tight coupling is harmless if code is in one class.
• Thinking validation and persistence are always linked.

5. You need to ensure that a class has only one instance throughout the application lifecycle, and this instance must be lazily initialized in a thread-safe manner without incurring synchronization overhead on every access. Which design approach best fits this requirement?

easy

A. Use a simple static variable without synchronization and rely on the language's memory model.

B. Use a synchronized method that creates the instance on first call, locking every time.

C. Create the instance eagerly at class loading time to avoid synchronization issues.

D. Implement double-checked locking with a volatile instance variable to minimize synchronization overhead.

Solution

1. Step 1: Understand the problem constraints

   The instance must be lazily initialized and thread-safe, but synchronization overhead should be minimized.

2. Step 2: Evaluate each approach

   Synchronized method locks on every call, causing overhead. Eager initialization is thread-safe but not lazy. Unsynchronized static variable risks multiple instances in multithreaded contexts. Double-checked locking with volatile ensures lazy init, thread safety, and minimal locking.

3. Final Answer:

   Option D -> Option D

4. Quick Check:

   Double-checked locking balances thread safety and performance [OK]

Hint: Double-checked locking minimizes synchronization overhead [OK]

Common Mistakes:

• Assuming synchronized method is efficient enough
• Believing eager initialization is always best
• Ignoring volatile keyword necessity