Polymorphism - Compile-Time (Overloading) vs Runtime (Overriding)

▶

Steps

setup

Define base class Shape

The base class Shape is defined with a draw() method that prints a generic message.

💡 This sets up the parent class that other shapes will inherit from, establishing the base behavior.

Line:

class Shape:
    def draw(self):
        print("Drawing a generic shape")

💡 Shape class provides a default draw() method to be overridden by subclasses.

setup

Define subclass Circle overriding draw()

Circle class inherits from Shape and overrides the draw() method to print a circle-specific message.

💡 This shows method overriding, a key part of runtime polymorphism.

Line:

class Circle(Shape):
    def draw(self):  # Overriding
        print("Drawing a circle")

💡 Circle provides its own implementation of draw(), replacing the base version.

setup

Define subclass Rectangle overriding draw()

Rectangle class inherits from Shape and overrides the draw() method to print a rectangle-specific message.

💡 Another example of overriding, reinforcing runtime polymorphism concept.

Line:

class Rectangle(Shape):
    def draw(self):  # Overriding
        print("Drawing a rectangle")

💡 Rectangle also customizes the draw() method, showing multiple subclasses can override the same method.

setup

Create instances of Circle, Rectangle, and Shape

Instantiate objects of Circle, Rectangle, and Shape classes and store them in a list.

💡 This prepares objects of different types to demonstrate polymorphic behavior.

Line:

shapes = [Circle(), Rectangle(), Shape()]

💡 Objects of different subclasses are stored in a common list typed as Shape references.

traverse

Start iteration over shapes list

Begin looping over the list of shape objects to call their draw() methods.

💡 This loop will invoke draw() on each object, demonstrating runtime polymorphism.

Line:

for shape in shapes:

💡 The loop variable 'shape' will reference each object in turn, regardless of its subclass.

compare

Call draw() on Circle instance

The first object is a Circle instance; calling draw() invokes Circle's overridden method.

💡 This demonstrates runtime polymorphism: the method called depends on the actual object type, not the reference type.

Line:

shape.draw()  # Runtime polymorphism via overriding

💡 At runtime, the Circle's draw() method overrides the base Shape method.

compare

Call draw() on Rectangle instance

The second object is a Rectangle instance; calling draw() invokes Rectangle's overridden method.

💡 Again, the method call resolves to the subclass's version at runtime.

Line:

shape.draw()  # Runtime polymorphism via overriding

💡 Each subclass can provide its own behavior for the same method signature.

compare

Call draw() on Shape instance

The third object is a Shape instance; calling draw() invokes the base class method.

💡 When no subclass overrides, the base class method is called.

Line:

shape.draw()  # Runtime polymorphism via overriding

💡 Polymorphism falls back to base class method if no override exists.

traverse

End of iteration

All objects in the list have had their draw() method called, demonstrating polymorphism.

💡 This completes the demonstration of runtime polymorphism via method overriding.

Line:

for shape in shapes:
    shape.draw()

💡 The loop successfully dispatched calls to the correct draw() method for each object.

reconstruct

Summary: Polymorphism in action

The example illustrates runtime polymorphism where the draw() method called depends on the actual object type, not the reference type.

💡 This final step consolidates understanding of overriding and dynamic dispatch.

Line:

for shape in shapes:
    shape.draw()

💡 Overriding enables different behaviors for the same method call, resolved at runtime.

class Shape:
    def draw(self):  # STEP 1
        print("Drawing a generic shape")

class Circle(Shape):
    def draw(self):  # STEP 2
        print("Drawing a circle")

class Rectangle(Shape):
    def draw(self):  # STEP 3
        print("Drawing a rectangle")

shapes = [Circle(), Rectangle(), Shape()]  # STEP 4

for shape in shapes:  # STEP 5
    shape.draw()  # STEPS 6,7,8

📊

Polymorphism - Compile-Time (Overloading) vs Runtime (Overriding) - Watch the Algorithm Execute, Step by Step

Watching each step reveals how polymorphism works internally, clarifying the difference between compile-time overloading and runtime overriding.

Defines base class with a concrete method to be overridden.

Shape

+draw()

Subclass overrides base class method to customize behavior.

Shape

+draw()

Circle

+draw()

Circle ▷ Shape

Multiple subclasses override the same base method.

Shape

+draw()

Circle

+draw()

Rectangle

+draw()

Circle ▷ ShapeRectangle ▷ Shape

Objects instantiated from classes to demonstrate polymorphism.

Shape

+draw()

Circle

+draw()

Rectangle

+draw()

Circle ▷ ShapeRectangle ▷ Shape

Loop setup to traverse polymorphic objects.

Shape

+draw()

Circle

+draw()

Rectangle

+draw()

Circle ▷ ShapeRectangle ▷ Shape

Runtime method dispatch selects subclass method.

Shape

+draw()

Circle

+draw()

Rectangle

+draw()

Circle ▷ ShapeRectangle ▷ Shape

Runtime dispatch calls correct subclass method.

Shape

+draw()

Circle

+draw()

Rectangle

+draw()

Circle ▷ ShapeRectangle ▷ Shape

Base class method called when no override exists.

Shape

+draw()

Circle

+draw()

Rectangle

+draw()

Circle ▷ ShapeRectangle ▷ Shape

Iteration complete, polymorphic calls demonstrated.

Shape

+draw()

Circle

+draw()

Rectangle

+draw()

Circle ▷ ShapeRectangle ▷ Shape

Final understanding of runtime polymorphism via overriding.

Shape

+draw()

Circle

+draw()

Rectangle

+draw()

Circle ▷ ShapeRectangle ▷ Shape

Key Takeaways

✓ Runtime polymorphism allows method calls to invoke the correct subclass implementation dynamically.

This dynamic dispatch is not obvious from reading code alone but is clear when watching method calls resolve at runtime.

✓ Overriding replaces base class methods in subclasses, enabling flexible behavior customization.

Seeing the overridden methods highlighted helps understand how subclasses change behavior.

✓ The base class method is called only if no subclass override exists, showing fallback behavior.

This clarifies that polymorphism does not always mean subclass methods are called; base methods remain accessible.

Practice

1. When a class inherits from multiple classes that have a method with the same name, describe the step-by-step process the Method Resolution Order (MRO) uses to determine which method is called.

easy

A. MRO uses a linearization algorithm that merges the order of parents and their ancestors to find the method.

B. MRO searches the first parent class fully before moving to the next parent class.

C. MRO always calls the method from the last parent class listed in the inheritance.

D. MRO randomly picks the method from any parent class that defines it.

Solution

1. Step 1: Understand naive search

   MRO does not simply search the first parent class fully before moving to the next; it uses a more sophisticated approach.

2. Step 2: Recognize MRO linearization

   MRO uses a specific linearization (like C3 linearization) that merges parent classes and their ancestors in a consistent order.

3. Step 3: Eliminate incorrect options

   MRO always calls the method from the last parent class listed in the inheritance is incorrect because the last parent is not always chosen; order and ancestors matter. MRO randomly picks the method from any parent class that defines it is incorrect because MRO is deterministic, not random.

4. Final Answer:

   Option A -> Option A

5. Quick Check:

   MRO merges inheritance hierarchies to find the correct method in a predictable order.

Hint: MRO = deterministic linearization of inheritance graph

Common Mistakes:

• Assuming simple left-to-right search suffices
• Believing last parent always overrides
• Thinking method choice is random

2. Considering extensibility in the Snake and Ladder game design, what is a key trade-off when embedding snakes and ladders directly as attributes inside the Board class versus modeling them as separate entities?

medium

A. Modeling snakes and ladders as separate entities increases runtime complexity significantly

B. Embedding snakes and ladders inside Board simplifies design but reduces flexibility to add new types of board elements later

C. Embedding snakes and ladders inside Board improves encapsulation and makes the Board immutable

D. Modeling snakes and ladders separately forces duplication of position data, increasing memory usage unnecessarily

Solution

1. Step 1: Embedding snakes/ladders inside Board

   This approach simplifies initial design but tightly couples Board to these elements.

2. Step 2: Impact on extensibility

   Tightly coupled design makes it harder to add new board elements (e.g., portals, traps) without modifying Board.

3. Step 3: Modeling as separate entities

   Allows easy extension by adding new element types without changing Board internals.

4. Step 4: Complexity and memory considerations

   Separate entities add minimal overhead; runtime complexity impact is negligible.

5. Final Answer:

   Option B -> Option B

6. Quick Check:

   Trade-off is between simplicity and extensibility, not runtime complexity or memory bloat.

Hint: Tight coupling simplifies now but blocks future extensions [OK]

Common Mistakes:

• Thinking separate entities cause big runtime overhead
• Believing embedding improves encapsulation and immutability
• Assuming separate entities cause memory bloat

3. Consider the following buggy code snippet from a thread-safe observer pattern implementation. Which line contains the subtle bug that can cause unsubscribed observers to still receive notifications?

def unsubscribe(self, observer, event_type):
    with self.lock:
        if event_type in self.observers:
            self.observers[event_type].remove(observer)
            if not self.observers[event_type]:
                del self.observers[event_type]

Assume that observer may not be subscribed to event_type when unsubscribe is called.

medium

A. Line 5: No handling of empty observer dictionary

B. Line 2: Lock is not acquired properly

C. Line 3: Missing check if observer is in the set before remove()

D. Line 4: Deleting event_type key prematurely

Solution

1. Step 1: Analyze unsubscribe logic

   Line 3 calls remove() on the set without checking if observer exists, which raises KeyError if observer not subscribed.

2. Step 2: Identify fix

   Check if observer in self.observers[event_type] before remove() to avoid errors and ensure proper removal.

3. Final Answer:

   Option C -> Option C

4. Quick Check:

   remove() without membership check causes runtime error [OK]

Hint: remove() without membership check can raise error [OK]

Common Mistakes:

• Assuming remove() silently ignores missing elements

4. Suppose you want to extend the Command Pattern to support commands that can be executed multiple times (reused) and also support undo/redo correctly. Which modification to the invoker's undo/redo management is necessary to handle this scenario without corrupting state?

hard

A. Store only one instance of each command and reuse it for all executions, pushing it multiple times onto undo stack.

B. Clear both undo and redo stacks after every command execution to avoid reuse issues.

C. Create a new command instance for each execution and push that instance onto the undo stack, ensuring undo/redo operate on the correct state snapshot.

D. Avoid using undo/redo stacks and instead recompute state from scratch on each undo or redo.

Solution

1. Step 1: Understand reuse implications

   Reusing the same command instance for multiple executions causes undo/redo to affect the wrong state because the command's internal state may change.

2. Step 2: Identify correct approach

   Creating a new command instance per execution ensures each undo/redo corresponds to the exact executed command instance and its parameters.

3. Step 3: Confirm undo/redo stack integrity

   This approach preserves correct ordering and state consistency during undo/redo operations.

4. Final Answer:

   Option C -> Option C

5. Quick Check:

   New instances per execution prevent state corruption on undo/redo [OK]

Hint: Each execution needs a fresh command instance for correct undo/redo [OK]

Common Mistakes:

• Reusing command instances causing incorrect undos
• Clearing stacks unnecessarily losing history

5. If the Library Management System must support reserving books that are currently loaned out, which design change best handles the edge case where multiple users reserve the same book simultaneously?

hard

A. Let the User class maintain their own reservation list independently without central coordination.

B. Allow multiple reservations by updating the book's status to 'reserved' without tracking order.

C. Add a reservation queue in the LoanManager and process reservations in FIFO order with atomic updates.

D. Implement a polling mechanism where users repeatedly check book availability without reservations.

Solution

1. Step 1: Why a reservation queue?

   FIFO queue ensures fairness and order in handling multiple reservations.

2. Step 2: Why not multiple reservations without order?

   Allow multiple reservations by updating the book's status to 'reserved' without tracking order. causes ambiguity and race conditions in fulfilling reservations.

3. Step 3: Why not user-maintained reservations?

   Let the User class maintain their own reservation list independently without central coordination. lacks centralized control, risking inconsistent reservation states.

4. Step 4: Why not polling without reservations?

   Implement a polling mechanism where users repeatedly check book availability without reservations. leads to poor user experience and race conditions.

5. Final Answer:

   Option C -> Option C

6. Quick Check:

   Centralized, ordered reservation management with atomic updates handles concurrency and fairness.

Hint: Use a centralized FIFO reservation queue to handle concurrent reservations fairly [OK]

Common Mistakes:

• Ignoring reservation order and fairness
• Decentralizing reservation tracking
• Relying on user polling instead of system-managed reservations