Decorator Pattern - Wrapping Behaviour Without Subclassing

▶

Steps

setup

Define Abstract Component Interface Coffee

The abstract class Coffee is defined with abstract methods cost() and description(). This sets the contract for all coffee-related classes.

💡 This step establishes the interface that all concrete coffees and decorators must implement, ensuring consistent behavior.

Line:

class Coffee(ABC):
    @abstractmethod
    def cost(self):
        pass

💡 All coffee types will share these methods, enabling decorators to wrap any Coffee object interchangeably.

setup

Implement Concrete Component SimpleCoffee

SimpleCoffee class implements Coffee interface, providing concrete cost and description methods returning base values.

💡 This is the core object that decorators will wrap to add behavior dynamically.

Line:

class SimpleCoffee(Coffee):
    def cost(self):
        return 5
    def description(self):
        return "Coffee"

💡 SimpleCoffee provides the base behavior that decorators will extend without modifying this class.

setup

Define Abstract Decorator CoffeeDecorator

CoffeeDecorator class inherits Coffee and holds a reference to a Coffee object to delegate calls.

💡 This class enables wrapping any Coffee object and forwarding method calls, forming the base for concrete decorators.

Line:

class CoffeeDecorator(Coffee):
    def __init__(self, coffee):
        self._coffee = coffee
    def cost(self):
        return self._coffee.cost()

💡 Decorator stores the wrapped object and delegates behavior, allowing dynamic extension.

setup

Implement MilkDecorator Extending CoffeeDecorator

MilkDecorator adds milk behavior by overriding cost and description, adding milk amount and cost to the wrapped coffee.

💡 This concrete decorator modifies behavior dynamically based on the amount parameter.

Line:

class MilkDecorator(CoffeeDecorator):
    def __init__(self, coffee, amount=1):
        super().__init__(coffee)
        self.amount = amount

💡 Decorator can add state and modify behavior while delegating to the wrapped object.

setup

Implement SugarDecorator Extending CoffeeDecorator

SugarDecorator adds sugar behavior by overriding cost and description, adding sugar amount and cost to the wrapped coffee.

💡 Another concrete decorator that dynamically modifies behavior based on amount.

Line:

class SugarDecorator(CoffeeDecorator):
    def __init__(self, coffee, amount=1):
        super().__init__(coffee)
        self.amount = amount

💡 Multiple decorators can be stacked to add different behaviors independently.

insert

Create SimpleCoffee Instance

Instantiate a SimpleCoffee object representing the base coffee with no additions.

💡 This is the starting point for decoration; the base object to wrap.

Line:

coffee = SimpleCoffee()

💡 The base coffee object has fixed cost and description before decoration.

insert

Wrap SimpleCoffee with MilkDecorator (amount=2)

Create a MilkDecorator wrapping the SimpleCoffee object, adding milk behavior with amount 2.

💡 Wrapping adds milk cost and description dynamically without changing SimpleCoffee.

Line:

coffee = MilkDecorator(coffee, amount=2)

💡 Decorator wraps the existing coffee object, extending behavior transparently.

insert

Wrap MilkDecorator with SugarDecorator (amount=3)

Create a SugarDecorator wrapping the MilkDecorator object, adding sugar behavior with amount 3.

💡 Stacking decorators allows combining multiple behaviors dynamically.

Line:

coffee = SugarDecorator(coffee, amount=3)

💡 Decorators can be stacked arbitrarily to compose complex behavior.

traverse

Call description() on SugarDecorator

Invoke description() on SugarDecorator, which calls description() on MilkDecorator, which calls SimpleCoffee, then appends sugar description.

💡 This shows how calls delegate through decorators, accumulating behavior.

Line:

print(coffee.description())  # Coffee, Milk(2), Sugar(3)

💡 Each decorator adds its own description after delegating to the wrapped object.

traverse

Call cost() on SugarDecorator

Invoke cost() on SugarDecorator, which calls cost() on MilkDecorator, which calls SimpleCoffee, then adds sugar cost.

💡 This shows how cost accumulates through the decorator chain.

Line:

print(coffee.cost())  # 5 + 1.0 + 0.6 = 6.6

💡 Each decorator adds its cost to the total by delegating and then augmenting the result.

from abc import ABC, abstractmethod

class Coffee(ABC):
    @abstractmethod
    def cost(self):
        pass  # STEP 1
    @abstractmethod
    def description(self):
        pass  # STEP 1

class SimpleCoffee(Coffee):
    def cost(self):
        return 5  # STEP 2
    def description(self):
        return "Coffee"  # STEP 2

class CoffeeDecorator(Coffee):
    def __init__(self, coffee):
        self._coffee = coffee  # STEP 3
    def cost(self):
        return self._coffee.cost()  # STEP 3
    def description(self):
        return self._coffee.description()  # STEP 3

class MilkDecorator(CoffeeDecorator):
    def __init__(self, coffee, amount=1):
        super().__init__(coffee)  # STEP 4
        self.amount = amount  # STEP 4
    def cost(self):
        return super().cost() + 0.5 * self.amount  # STEP 4
    def description(self):
        return super().description() + f", Milk({self.amount})"  # STEP 4

class SugarDecorator(CoffeeDecorator):
    def __init__(self, coffee, amount=1):
        super().__init__(coffee)  # STEP 5
        self.amount = amount  # STEP 5
    def cost(self):
        return super().cost() + 0.2 * self.amount  # STEP 5
    def description(self):
        return super().description() + f", Sugar({self.amount})"  # STEP 5

if __name__ == "__main__":
    coffee = SimpleCoffee()  # STEP 6
    coffee = MilkDecorator(coffee, amount=2)  # STEP 7
    coffee = SugarDecorator(coffee, amount=3)  # STEP 8
    print(coffee.description())  # STEP 9
    print(coffee.cost())  # STEP 10

📊

Decorator Pattern - Wrapping Behaviour Without Subclassing - Watch the Algorithm Execute, Step by Step

Watching this step-by-step helps you understand how decorators add behavior without subclassing, by wrapping objects and forwarding method calls.

Defines the abstract component interface for the Decorator pattern.

«abstract»Coffee

+cost()

+description()

Concrete component implements the component interface.

«abstract»Coffee

+cost()

+description()

SimpleCoffee

+cost()

+description()

SimpleCoffee ▷ Coffee (1:1)

Abstract decorator holds a reference to a Coffee component and delegates calls.

«abstract»Coffee

+cost()

+description()

SimpleCoffee

+cost()

+description()

CoffeeDecorator

−_coffee: Coffee

+__init__()

+cost()

+description()

SimpleCoffee ▷ Coffee (1:1)CoffeeDecorator ▷ Coffee (1:1)

Concrete decorator adds new behavior and state.

«abstract»Coffee

+cost()

+description()

SimpleCoffee

+cost()

+description()

CoffeeDecorator

−_coffee: Coffee

+__init__()

+cost()

+description()

MilkDecorator

−amount: int

+__init__()

+cost()

+description()

SimpleCoffee ▷ Coffee (1:1)CoffeeDecorator ▷ Coffee (1:1)MilkDecorator ▷ CoffeeDecorator (1:1)

Another concrete decorator adds behavior independently.

«abstract»Coffee

+cost()

+description()

SimpleCoffee

+cost()

+description()

CoffeeDecorator

−_coffee: Coffee

+__init__()

+cost()

+description()

MilkDecorator

−amount: int

+__init__()

+cost()

+description()

SugarDecorator

−amount: int

+__init__()

+cost()

+description()

SimpleCoffee ▷ Coffee (1:1)CoffeeDecorator ▷ Coffee (1:1)MilkDecorator ▷ CoffeeDecorator (1:1)SugarDecorator ▷ CoffeeDecorator (1:1)

Instantiated concrete component object.

SimpleCoffee

+cost()

+description()

Decorator wraps component to add milk behavior.

MilkDecorator

−_coffee: SimpleCoffee

−amount: int

+cost()

+description()

SimpleCoffee

+cost()

+description()

MilkDecorator ◆ SimpleCoffee (1:1)

Stacked decorators compose behavior dynamically.

SugarDecorator

−_coffee: MilkDecorator

−amount: int

+cost()

+description()

MilkDecorator

−_coffee: SimpleCoffee

−amount: int

+cost()

+description()

SimpleCoffee

+cost()

+description()

SugarDecorator ◆ MilkDecorator (1:1)MilkDecorator ◆ SimpleCoffee (1:1)

Delegation chain for description method.

SugarDecorator

−_coffee: MilkDecorator

−amount: int

+description()

MilkDecorator

−_coffee: SimpleCoffee

−amount: int

+description()

SimpleCoffee

+description()

SugarDecorator ◆ MilkDecorator (1:1)MilkDecorator ◆ SimpleCoffee (1:1)

Delegation chain for cost method.

SugarDecorator

−_coffee: MilkDecorator

−amount: int

+cost()

MilkDecorator

−_coffee: SimpleCoffee

−amount: int

+cost()

SimpleCoffee

+cost()

SugarDecorator ◆ MilkDecorator (1:1)MilkDecorator ◆ SimpleCoffee (1:1)

Key Takeaways

✓ Decorators wrap objects to add behavior dynamically without subclassing.

This is hard to see from code alone because the wrapping and delegation happen at runtime and are invisible in static class hierarchies.

✓ Method calls delegate through the decorator chain, accumulating behavior step-by-step.

Visualizing each call clarifies how each decorator contributes to the final result.

✓ Stacking multiple decorators composes complex behavior flexibly and transparently.

The trace shows how each decorator wraps the previous one, enabling modular extensions.

Practice

1. When a class implements an interface and also extends an abstract class, what is the sequence of abstraction enforcement and implementation that occurs during object instantiation?

easy

A. The abstract class constructor runs, but interface methods have no implementation to run.

B. Interface methods are implemented first, then the abstract class constructor runs.

C. The class must implement interface methods before the abstract class constructor runs.

D. The abstract class's constructor runs first, then interface methods are implemented by the class.

Solution

1. Step 1: Understand interface role

   Interfaces declare methods but provide no implementation or constructors.

2. Step 2: Abstract class constructor behavior

   Abstract class constructors run during instantiation to initialize shared state.

3. Step 3: Implementation of interface methods

   The class implementing the interface provides method bodies; no constructor or code runs from interface itself.

4. Final Answer:

   Option A -> Option A

5. Quick Check:

   Interfaces define contracts only; abstract class constructors run during instantiation.

Hint: Interface methods have no constructor or implementation to run; abstract class constructors always run.

Common Mistakes:

• Thinking interface methods have constructors or code to execute.
• Believing interface implementation order affects constructor execution.
• Confusing interface method implementation with constructor invocation.

2. You are designing a system that manages user accounts and sends notification emails. According to the Single Responsibility Principle, how should you organize these responsibilities?

easy

A. Separate user account management and email notification into different classes because each has a different reason to change.

B. Combine user account management and email notification in one class because they are related to users.

C. Put all user-related functionalities, including notifications, into a single class to reduce the number of classes.

D. Create one class for user management and embed email notification logic inside its methods to simplify interactions.

Solution

1. Step 1: Identify reasons to change

   User account management changes when user data or authentication changes; email notifications change when messaging or delivery requirements change.

2. Step 2: Apply SRP

   Since these reasons to change differ, they should be separated into different classes to avoid coupling unrelated changes.

3. Step 3: Evaluate other options

   Options A, C, and D combine responsibilities, increasing coupling and reducing cohesion, violating SRP.

4. Final Answer:

   Option A -> Option A

5. Quick Check:

   Separate classes for distinct reasons to change -> SRP compliant.

Hint: One class, one reason to change.

Common Mistakes:

• Assuming related domain means same responsibility.
• Combining functionalities to reduce class count.
• Embedding multiple responsibilities for convenience.

3. Which of the following statements about using inheritance to model different vehicle types in the parking lot system is INCORRECT?

medium

A. Inheritance allows sharing common vehicle attributes and behaviors in a base Vehicle class

B. Using inheritance for vehicle types can lead to rigid designs that are hard to extend with new types

C. Inheritance is always the best approach to add new vehicle types without modifying existing code

D. Polymorphism enables treating all vehicle types uniformly when allocating parking spots

Solution

1. Step 1: Review inheritance benefits

   Inheritance supports code reuse and polymorphism for uniform handling.

2. Step 2: Recognize limitations

   Inheritance hierarchies can become rigid and hard to extend, violating open-closed principle.

3. Step 3: Identify incorrect statement

   Claiming inheritance is always best ignores alternatives like composition or interfaces that improve extensibility.

4. Final Answer:

   Option C -> Option C

5. Quick Check:

   Inheritance is not always best for extensibility [OK]

Hint: Inheritance can cause rigidity; prefer composition for extensibility [OK]

Common Mistakes:

• Assuming inheritance is always the best design choice
• Ignoring polymorphism benefits

4. What is the time complexity of notifying observers in the thread-safe observer pattern implementation where observers are stored in a dictionary mapping event types to sets of observers, and a snapshot list is created during notification?

medium

A. O(n) where n is total number of all observers across all event types

B. O(k) where k is the number of observers subscribed to the notified event type

C. O(k + n) where k is observers for event type and n is total observers

D. O(1) constant time due to hash set usage

Solution

1. Step 1: Identify the data structure and notification process

   Observers are stored per event type in sets. Notification locks and copies only the observers for the specific event type.

2. Step 2: Analyze complexity of notify()

   Notify creates a snapshot list of observers for the event type (size k) and iterates over it, so time is proportional to k, not total n.

3. Final Answer:

   Option B -> Option B

4. Quick Check:

   Notify cost depends only on observers for that event type [OK]

Hint: Notify complexity depends on observers for event type only [OK]

Common Mistakes:

• Assuming notify iterates over all observers regardless of event type

5. In a legacy system, a class handles both business logic and logging. You want to refactor it following SRP, but the logging code is tightly intertwined with business logic. What is the best approach to refactor this while respecting SRP?

hard

A. Ignore SRP in this case because legacy code should not be refactored.

B. Leave logging inside the class because extracting it would break existing functionality and increase risk.

C. Merge business logic and logging into a utility class to centralize all cross-cutting concerns.

D. Extract logging into a separate class and replace logging calls with calls to this new class, even if it requires modifying many places.

Solution

1. Step 1: Identify responsibilities

   Business logic and logging are separate reasons to change.

2. Step 2: Refactor strategy

   Extract logging into its own class to isolate changes related to logging.

3. Step 3: Address tight coupling

   Though intertwined, refactoring calls to the new logging class improves maintainability and respects SRP.

4. Step 4: Evaluate other options

   Options B and D avoid refactoring, risking future issues; C increases coupling by merging unrelated concerns.

5. Final Answer:

   Option D -> Option D

6. Quick Check:

   Extract and isolate responsibilities even if it requires effort -> SRP compliance.

Hint: Separate concerns even if intertwined; refactor stepwise.

Common Mistakes:

• Avoiding refactoring due to perceived risk.
• Merging unrelated concerns for convenience.
• Ignoring SRP in legacy code.