← Python

Design Patterns in Python

← Design Patterns in Python

Select a question from the sidebar

18 questions in this topic

Question 1 / 18

How do you implement the Singleton pattern in Python?

The Singleton pattern ensures a class has only one instance and provides a global point of access to it. In Python, there are several ways to implement it:

Module-level variable (most Pythonic): Python modules are singletons by nature. Import the same module twice and you get the same object.
__new__ override: Control instance creation by caching the first instance.
Metaclass: A metaclass that intercepts class creation.
Decorator: Wrap a class to cache its instance.

The module-level approach is the most Pythonic because Python modules are already singletons.

Pseudo Code

Module-level: Just use a module variable
__new__: Override __new__ to return cached instance
Metaclass: type.__call__ checks for existing instance
Decorator: Wrap class; return same instance on repeated calls

Code

# Method 1: Module-level singleton (most Pythonic)
# config.py
class _Config:
    def __init__(self):
        self.debug = False
        self.database_url = 'sqlite:///app.db'

config = _Config()  # Module-level instance
# Usage: from config import config
# Every import gets the same instance

# Method 2: __new__ override
class Singleton:
    _instance = None

    def __new__(cls, *args, **kwargs):
        if cls._instance is None:
            cls._instance = super().__new__(cls)
        return cls._instance

    def __init__(self, value=None):
        if not hasattr(self, '_initialized'):
            self.value = value
            self._initialized = True

a = Singleton('first')
b = Singleton('second')
print(a is b)       # True
print(a.value)      # 'first' (not overwritten)

# Method 3: Metaclass singleton
class SingletonMeta(type):
    _instances = {}

    def __call__(cls, *args, **kwargs):
        if cls not in cls._instances:
            cls._instances[cls] = super().__call__(*args, **kwargs)
        return cls._instances[cls]

class Database(metaclass=SingletonMeta):
    def __init__(self, url='sqlite:///app.db'):
        self.url = url
        print(f'Connecting to {url}')

db1 = Database()                     # 'Connecting to sqlite:///app.db'
db2 = Database('postgres://...')      # No output; returns existing instance
print(db1 is db2)                     # True

# Method 4: Decorator singleton
def singleton(cls):
    instances = {}
    def get_instance(*args, **kwargs):
        if cls not in instances:
            instances[cls] = cls(*args, **kwargs)
        return instances[cls]
    return get_instance

@singleton
class Logger:
    def __init__(self, name='app'):
        self.name = name

    def log(self, message):
        print(f'[{self.name}] {message}')

logger1 = Logger()
logger2 = Logger('other')  # Ignored; returns existing
print(logger1 is logger2)  # True

True
first
Connecting to sqlite:///app.db
True
True

Key Points

•Module-level variables are the most Pythonic singleton (modules are cached after first import)
•__new__ is called before __init__; override it to return a cached instance
•Metaclass approach is cleanest for multiple singleton classes
•Decorator approach is simple but changes the class to a function (breaks isinstance)
•Guard __init__ with a flag to prevent re-initialization

Gotchas

•__init__ is called every time even with __new__ singleton; guard with _initialized flag
•The decorator approach replaces the class with a function, breaking isinstance checks
•Singletons make unit testing harder because state persists between tests
•Thread safety: add threading.Lock() for multithreaded singleton creation

Most Pythonic: use a module-level instance (modules are singletons). Alternatives: override __new__ to cache the instance, use a metaclass, or a decorator. Guard __init__ with a flag to prevent re-initialization.

•Module-level is most Pythonic; __new__ or metaclass for OOP approach
•Guard __init__ to prevent re-initialization

# Module singleton (best)
# config.py
class _Config:
    debug = False
config = _Config()

# __new__ singleton
class Singleton:
    _instance = None
    def __new__(cls):
        if cls._instance is None:
            cls._instance = super().__new__(cls)
        return cls._instance

Singletons make testing harder; consider dependency injection instead

Question 2 / 18

How do you implement the Factory pattern in Python?

The Factory pattern encapsulates object creation, letting you create objects without specifying their exact class. Python supports several factory variants:

Simple Factory: A function or method that returns different classes based on input.
Factory Method: A method in a base class that subclasses override to create specific objects.
Abstract Factory: A factory that produces families of related objects.

In Python, simple factories are often just functions (no need for a Factory class). Dictionaries mapping names to classes are a clean Pythonic approach.

Pseudo Code

Simple Factory: function returns different classes based on input
Factory Method: base class defines create(); subclasses override
Abstract Factory: create families of related objects
Pythonic: dict mapping names to classes

Code

from abc import ABC, abstractmethod

# --- Simple Factory ---
class Dog:
    def speak(self) -> str:
        return "Woof!"

class Cat:
    def speak(self) -> str:
        return "Meow!"

class Bird:
    def speak(self) -> str:
        return "Tweet!"

# Pythonic simple factory using a dict
def create_animal(animal_type: str):
    animals = {
        'dog': Dog,
        'cat': Cat,
        'bird': Bird,
    }
    cls = animals.get(animal_type.lower())
    if cls is None:
        raise ValueError(f"Unknown animal type: {animal_type}")
    return cls()

dog = create_animal('dog')
print(dog.speak())  # "Woof!"

# --- Factory Method ---
class Document(ABC):
    @abstractmethod
    def create_page(self) -> 'Page':
        ...

    def render(self) -> str:
        page = self.create_page()  # Factory method
        return page.content()

class Page(ABC):
    @abstractmethod
    def content(self) -> str:
        ...

class HTMLPage(Page):
    def content(self) -> str:
        return "<html><body>Hello</body></html>"

class PDFPage(Page):
    def content(self) -> str:
        return "%PDF-1.4 Hello"

class HTMLDocument(Document):
    def create_page(self) -> Page:
        return HTMLPage()

class PDFDocument(Document):
    def create_page(self) -> Page:
        return PDFPage()

doc = HTMLDocument()
print(doc.render())  # "<html><body>Hello</body></html>"

# --- Abstract Factory ---
class Button(ABC):
    @abstractmethod
    def render(self) -> str: ...

class TextBox(ABC):
    @abstractmethod
    def render(self) -> str: ...

class UIFactory(ABC):
    @abstractmethod
    def create_button(self) -> Button: ...
    @abstractmethod
    def create_textbox(self) -> TextBox: ...

# Light theme family
class LightButton(Button):
    def render(self) -> str:
        return "[Light Button]"

class LightTextBox(TextBox):
    def render(self) -> str:
        return "[Light TextBox]"

class LightUIFactory(UIFactory):
    def create_button(self) -> Button:
        return LightButton()
    def create_textbox(self) -> TextBox:
        return LightTextBox()

# Dark theme family
class DarkButton(Button):
    def render(self) -> str:
        return "[Dark Button]"

class DarkTextBox(TextBox):
    def render(self) -> str:
        return "[Dark TextBox]"

class DarkUIFactory(UIFactory):
    def create_button(self) -> Button:
        return DarkButton()
    def create_textbox(self) -> TextBox:
        return DarkTextBox()

def build_ui(factory: UIFactory) -> str:
    btn = factory.create_button()
    txt = factory.create_textbox()
    return f"{btn.render()} {txt.render()}"

print(build_ui(DarkUIFactory()))  # "[Dark Button] [Dark TextBox]"

Woof!
<html><body>Hello</body></html>
[Dark Button] [Dark TextBox]

Key Points

•Simple Factory: a function/dict that returns instances based on input (most Pythonic)
•Factory Method: base class defines creation interface; subclasses implement it
•Abstract Factory: creates families of related objects (e.g., themed UI components)
•Dict-based factories are cleaner in Python than class hierarchies for simple cases
•Factory patterns decouple creation from usage, enabling flexibility and testability

Gotchas

•Over-engineering: a simple dict factory often suffices; avoid factory classes when unnecessary
•Factory Method requires inheritance; in Python, passing a callable is often simpler
•Type hints for factories returning different types need Union or Protocol

Simple Factory: a function/dict maps names to classes. Factory Method: base class defines a creation method, subclasses override it. Abstract Factory: creates families of related objects. In Python, dict-based factories are the most common.

•Dict mapping is the most Pythonic factory; avoid over-engineering
•Factory Method uses inheritance; Abstract Factory for related object families

# Simple factory (Pythonic)
def create_animal(kind: str):
    animals = {'dog': Dog, 'cat': Cat, 'bird': Bird}
    cls = animals.get(kind)
    if not cls:
        raise ValueError(f"Unknown: {kind}")
    return cls()

# Factory method
class Document(ABC):
    @abstractmethod
    def create_page(self) -> Page: ...
    def render(self):
        return self.create_page().content()

A dict factory often replaces the need for Factory classes in Python

Question 3 / 18

How do you implement the Observer pattern in Python?

The Observer pattern (also called Publish-Subscribe) defines a one-to-many dependency so that when one object (subject) changes state, all its dependents (observers) are notified.

Python implementations:

Callback-based (most Pythonic): Store a list of callback functions.
Class-based: Define an Observer interface with an update() method.
Event system: Named events with multiple handlers per event.

The callback-based approach is most natural in Python due to first-class functions.

Pseudo Code

1. Subject maintains a list of callbacks/observers
2. Observers register via subscribe(callback)
3. When state changes, subject calls all registered callbacks
4. Observers unregister via unsubscribe(callback)

Code

from typing import Callable, Any

# Method 1: Callback-based (most Pythonic)
class EventEmitter:
    def __init__(self):
        self._listeners: dict[str, list[Callable]] = {}

    def on(self, event: str, callback: Callable) -> None:
        self._listeners.setdefault(event, []).append(callback)

    def off(self, event: str, callback: Callable) -> None:
        if event in self._listeners:
            self._listeners[event].remove(callback)

    def emit(self, event: str, *args: Any, **kwargs: Any) -> None:
        for callback in self._listeners.get(event, []):
            callback(*args, **kwargs)

# Usage
class UserService(EventEmitter):
    def create_user(self, name: str) -> dict:
        user = {'name': name, 'id': 1}
        self.emit('user_created', user)
        return user

    def delete_user(self, user_id: int) -> None:
        self.emit('user_deleted', user_id)

# Subscribe to events
service = UserService()
service.on('user_created', lambda user: print(f"Welcome email to {user['name']}"))
service.on('user_created', lambda user: print(f"Audit log: created {user['name']}"))
service.on('user_deleted', lambda uid: print(f"Cleanup for user {uid}"))

service.create_user('Alice')
# Output:
# Welcome email to Alice
# Audit log: created Alice

# Method 2: Class-based Observer
from abc import ABC, abstractmethod

class Observer(ABC):
    @abstractmethod
    def update(self, event: str, data: Any) -> None:
        ...

class Subject:
    def __init__(self):
        self._observers: list[Observer] = []

    def attach(self, observer: Observer) -> None:
        self._observers.append(observer)

    def detach(self, observer: Observer) -> None:
        self._observers.remove(observer)

    def notify(self, event: str, data: Any = None) -> None:
        for observer in self._observers:
            observer.update(event, data)

class EmailNotifier(Observer):
    def update(self, event: str, data: Any) -> None:
        if event == 'order_placed':
            print(f"Sending order confirmation for {data}")

class InventoryManager(Observer):
    def update(self, event: str, data: Any) -> None:
        if event == 'order_placed':
            print(f"Updating inventory for {data}")

class OrderService(Subject):
    def place_order(self, item: str) -> None:
        print(f"Order placed: {item}")
        self.notify('order_placed', item)

order_service = OrderService()
order_service.attach(EmailNotifier())
order_service.attach(InventoryManager())
order_service.place_order('Laptop')
# Order placed: Laptop
# Sending order confirmation for Laptop
# Updating inventory for Laptop

Welcome email to Alice
Audit log: created Alice
Order placed: Laptop
Sending order confirmation for Laptop
Updating inventory for Laptop

Key Points

•Callback-based is most Pythonic; class-based is more traditional
•EventEmitter pattern supports multiple named events with multiple handlers
•Observers are decoupled from the subject (loose coupling)
•on/off for subscribe/unsubscribe; emit to notify all observers
•Useful for cross-cutting concerns: logging, email, audit, cache invalidation

Gotchas

•Storing lambda callbacks makes unsubscribing difficult (lambdas are not equal by identity)
•Exceptions in one observer can prevent others from being notified; wrap in try/except
•Memory leaks: observers hold references to subjects; use weakref for long-lived observers

Observer lets objects subscribe to events. Pythonic approach: store callback functions in a dict by event name. Call all registered callbacks when an event occurs. Decouples event producers from consumers.

•Dict of event->callback list is the Pythonic approach
•Decouples producers from consumers

class EventEmitter:
    def __init__(self):
        self._listeners = {}
    def on(self, event, callback):
        self._listeners.setdefault(event, []).append(callback)
    def emit(self, event, *args):
        for cb in self._listeners.get(event, []):
            cb(*args)

emitter = EventEmitter()
emitter.on('save', lambda data: print(f'Saved: {data}'))
emitter.emit('save', {'id': 1})

Saved: {'id': 1}

Wrap observer calls in try/except to prevent one failure from blocking others

Question 4 / 18

How do you implement the Strategy pattern in Python?

The Strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. The client can switch algorithms at runtime.

Python makes this trivially easy because functions are first-class objects -- you can pass them around. There is no need for a Strategy interface class in most cases.

Two approaches:

Function-based (Pythonic): Pass strategy functions directly.
Class-based (traditional): Define a Strategy ABC with concrete implementations.

Pseudo Code

1. Define strategy as a function or class with a common interface
2. Pass the strategy to the context (client)
3. Context calls the strategy without knowing its internals
4. Switch strategies at runtime by passing a different one

Code

from typing import Callable

# Method 1: Function-based (most Pythonic)
def sort_by_name(users: list[dict]) -> list[dict]:
    return sorted(users, key=lambda u: u['name'])

def sort_by_age(users: list[dict]) -> list[dict]:
    return sorted(users, key=lambda u: u['age'])

def sort_by_score(users: list[dict]) -> list[dict]:
    return sorted(users, key=lambda u: u['score'], reverse=True)

def display_users(users: list[dict], strategy: Callable) -> None:
    sorted_users = strategy(users)
    for user in sorted_users:
        print(f"{user['name']}: age={user['age']}, score={user['score']}")

users = [
    {'name': 'Charlie', 'age': 30, 'score': 85},
    {'name': 'Alice', 'age': 25, 'score': 92},
    {'name': 'Bob', 'age': 35, 'score': 78},
]

display_users(users, sort_by_name)   # Alice, Bob, Charlie
display_users(users, sort_by_score)  # Alice, Charlie, Bob

# Method 2: Class-based (for complex strategies with state)
from abc import ABC, abstractmethod

class PricingStrategy(ABC):
    @abstractmethod
    def calculate(self, base_price: float) -> float:
        ...

class RegularPricing(PricingStrategy):
    def calculate(self, base_price: float) -> float:
        return base_price

class DiscountPricing(PricingStrategy):
    def __init__(self, discount_percent: float):
        self.discount = discount_percent / 100

    def calculate(self, base_price: float) -> float:
        return base_price * (1 - self.discount)

class BulkPricing(PricingStrategy):
    def __init__(self, threshold: int, discount_percent: float):
        self.threshold = threshold
        self.discount = discount_percent / 100

    def calculate(self, base_price: float) -> float:
        return base_price * (1 - self.discount)

class ShoppingCart:
    def __init__(self, pricing: PricingStrategy):
        self.pricing = pricing
        self.items: list[tuple[str, float]] = []

    def add_item(self, name: str, price: float) -> None:
        self.items.append((name, price))

    def set_pricing(self, pricing: PricingStrategy) -> None:
        self.pricing = pricing  # Change strategy at runtime

    def total(self) -> float:
        return sum(self.pricing.calculate(price) for _, price in self.items)

cart = ShoppingCart(RegularPricing())
cart.add_item('Widget', 100)
cart.add_item('Gadget', 200)
print(f"Regular: ${cart.total()}")  # $300.0

cart.set_pricing(DiscountPricing(20))
print(f"20% off: ${cart.total()}")  # $240.0

# Method 3: Dict-based strategy selection
strategies = {
    'regular': RegularPricing(),
    'holiday': DiscountPricing(15),
    'bulk': BulkPricing(10, 25),
}

def get_pricing(name: str) -> PricingStrategy:
    if name not in strategies:
        raise ValueError(f"Unknown strategy: {name}")
    return strategies[name]

Alice: age=25, score=92
Bob: age=35, score=78
Charlie: age=30, score=85
Alice: age=25, score=92
Charlie: age=30, score=85
Bob: age=35, score=78
Regular: $300
20% off: $240.0

Key Points

•Function-based is most Pythonic: pass functions as strategies (no class needed)
•Class-based when strategies have state or complex logic
•Strategies can be swapped at runtime via setter or constructor
•Dict mapping names to strategies is clean for configuration-driven selection
•Follows Open/Closed principle: add new strategies without modifying existing code

Gotchas

•Over-engineering: if you only have 2-3 strategies, a simple if/else may be clearer
•Function strategies cannot hold state; use classes or closures for stateful strategies
•Make sure all strategies have the same interface (same parameters and return type)

Strategy encapsulates interchangeable algorithms. In Python, simply pass functions (first-class objects) as strategies. Use classes when strategies need state. Swap strategies at runtime.

•Pass functions as strategies; no class needed in Python
•Use classes for stateful strategies

# Function-based (Pythonic)
def sort_by_name(items): return sorted(items, key=lambda x: x['name'])
def sort_by_date(items): return sorted(items, key=lambda x: x['date'])

def display(items, strategy):
    for item in strategy(items):
        print(item)

display(items, sort_by_name)  # Switch strategy easily

All strategies must have the same signature

Question 5 / 18

What is the difference between the Decorator pattern and Python decorators?

These share a name but are different concepts:

Decorator Pattern (GoF design pattern): A structural pattern that adds behavior to an object by wrapping it in another object with the same interface. Each wrapper adds a layer of functionality.

Python Decorators (@decorator): A language feature that modifies or wraps functions/classes. Uses the @ syntax. More like a general-purpose wrapper mechanism.

Python decorators CAN implement the Decorator Pattern, but they are more general -- they can do anything: add logging, check permissions, cache results, register routes, etc.

Pseudo Code

Decorator Pattern: Wrap object in layers, each adding behavior
Python @decorator: Wrap function/class to modify behavior
Key difference: Pattern wraps objects; @ wraps functions/classes

Code

# --- Decorator PATTERN (GoF) ---
from abc import ABC, abstractmethod

class Coffee(ABC):
    @abstractmethod
    def cost(self) -> float: ...
    @abstractmethod
    def description(self) -> str: ...

class SimpleCoffee(Coffee):
    def cost(self) -> float:
        return 2.00
    def description(self) -> str:
        return "Simple coffee"

# Decorators wrap the same interface
class CoffeeDecorator(Coffee):
    def __init__(self, coffee: Coffee):
        self._coffee = coffee

class MilkDecorator(CoffeeDecorator):
    def cost(self) -> float:
        return self._coffee.cost() + 0.50
    def description(self) -> str:
        return self._coffee.description() + ", milk"

class SugarDecorator(CoffeeDecorator):
    def cost(self) -> float:
        return self._coffee.cost() + 0.25
    def description(self) -> str:
        return self._coffee.description() + ", sugar"

class WhipDecorator(CoffeeDecorator):
    def cost(self) -> float:
        return self._coffee.cost() + 0.75
    def description(self) -> str:
        return self._coffee.description() + ", whip"

# Stack decorators
coffee = SimpleCoffee()
coffee = MilkDecorator(coffee)
coffee = SugarDecorator(coffee)
coffee = WhipDecorator(coffee)
print(f"{coffee.description()}: ${coffee.cost():.2f}")
# "Simple coffee, milk, sugar, whip: $3.50"

# --- Python @DECORATOR ---
import functools
import time

def timer(func):
    @functools.wraps(func)
    def wrapper(*args, **kwargs):
        start = time.time()
        result = func(*args, **kwargs)
        print(f"{func.__name__} took {time.time() - start:.3f}s")
        return result
    return wrapper

def cache(func):
    memo = {}
    @functools.wraps(func)
    def wrapper(*args):
        if args not in memo:
            memo[args] = func(*args)
        return memo[args]
    return wrapper

@timer
@cache
def fibonacci(n: int) -> int:
    if n < 2:
        return n
    return fibonacci(n - 1) + fibonacci(n - 2)

# Stacked decorators: cache wraps fibonacci, then timer wraps the result
print(fibonacci(30))

# Expected Output: (timing values are approximate)
# Simple coffee, milk, sugar, whip: $3.50
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# fibonacci took 0.000s
# 832040

Key Points

•Decorator Pattern: wraps objects with same interface to add behavior layers
•Python @decorator: wraps functions/classes, more general-purpose
•Pattern decorators are stackable objects; Python decorators are stackable function wrappers
•Both use composition over inheritance to extend behavior
•Python decorators are more common and flexible; Pattern is for object decoration

Gotchas

•Always use @functools.wraps in Python decorators to preserve __name__ and __doc__
•Decorator Pattern requires all decorators to implement the same interface
•Stacking order matters: @timer @cache is different from @cache @timer

Decorator Pattern wraps objects in layers with the same interface. Python @decorator wraps functions/classes. Both add behavior through composition, but @decorator is more general. Pattern is for object wrapping; @decorator is a language feature.

•Pattern wraps objects (same interface); @decorator wraps functions/classes
•Both use composition to extend behavior

# Decorator Pattern: object wrapping
coffee = SimpleCoffee()
coffee = MilkDecorator(coffee)   # Same interface, adds milk
coffee = SugarDecorator(coffee)  # Same interface, adds sugar

# Python @decorator: function wrapping
@timer
@cache
def expensive(n): ...

Use @functools.wraps to preserve wrapped function metadata

Question 6 / 18

How do you implement the Iterator pattern in Python?

The Iterator pattern provides a way to access elements of a collection sequentially without exposing its underlying representation. Python has built-in support through the iterator protocol:

Iterable: An object with __iter__() that returns an iterator.
Iterator: An object with __next__() that returns the next value or raises StopIteration.

Python also provides generators (yield), which are the easiest way to create iterators.

Pseudo Code

1. Iterable: class with __iter__() returning an iterator
2. Iterator: class with __next__() and __iter__() (returns self)
3. Generator: function with yield (simplest approach)
4. for loop automatically calls __iter__() then __next__() repeatedly

Code

# Method 1: Iterator class
class Countdown:
    def __init__(self, start: int):
        self.start = start

    def __iter__(self):
        return CountdownIterator(self.start)

class CountdownIterator:
    def __init__(self, current: int):
        self.current = current

    def __iter__(self):
        return self  # Iterators return themselves

    def __next__(self) -> int:
        if self.current <= 0:
            raise StopIteration
        value = self.current
        self.current -= 1
        return value

for num in Countdown(5):
    print(num)  # 5, 4, 3, 2, 1

# Method 2: Generator function (much simpler)
def countdown(start: int):
    current = start
    while current > 0:
        yield current
        current -= 1

for num in countdown(5):
    print(num)  # 5, 4, 3, 2, 1

# Method 3: Class with __iter__ as generator
class FileLines:
    def __init__(self, filepath: str):
        self.filepath = filepath

    def __iter__(self):
        with open(self.filepath) as f:
            for line in f:
                yield line.strip()

# Lazy iteration (memory efficient)
for line in FileLines('data.txt'):
    print(line)

# Real-world: paginated API iterator
class PaginatedAPI:
    def __init__(self, base_url: str, per_page: int = 100):
        self.base_url = base_url
        self.per_page = per_page

    def __iter__(self):
        page = 1
        while True:
            import requests
            resp = requests.get(
                self.base_url,
                params={'page': page, 'per_page': self.per_page}
            )
            items = resp.json().get('results', [])
            if not items:
                return  # StopIteration
            yield from items  # Yield each item
            page += 1

# Iterate through all pages transparently
# for user in PaginatedAPI('https://api.example.com/users'):
#     print(user['name'])

5
4
3
2
1
5
4
3
2
1
BBAACC

Key Points

•__iter__ returns an iterator; __next__ returns values or raises StopIteration
•Generator functions (yield) are the simplest way to create iterators
•yield from delegates to a sub-iterator
•Iterators are lazy; they compute values on demand (memory efficient)
•for loops automatically handle the iterator protocol

Gotchas

•Iterators are single-use: once exhausted, calling next() keeps raising StopIteration
•To iterate multiple times, the iterable must create a new iterator each time in __iter__
•A generator function returns a generator object; it does not run until you iterate

Implement __iter__ (returns iterator) and __next__ (returns next value / raises StopIteration). Easiest: use yield in a generator function. Iterators are lazy and memory-efficient.

•yield is the simplest iterator; __iter__/__next__ for class-based
•Iterators are single-use and lazy

# Generator (simplest)
def countdown(n):
    while n > 0:
        yield n
        n -= 1

for x in countdown(5):
    print(x)  # 5, 4, 3, 2, 1

# Class-based
class Range:
    def __init__(self, n):
        self.n = n
    def __iter__(self):
        i = 0
        while i < self.n:
            yield i
            i += 1

Iterators exhaust after one pass; create a new one for re-iteration

Question 7 / 18

How do you implement the Command pattern in Python?

The Command pattern encapsulates a request as an object, letting you parameterize clients with different requests, queue or log requests, and support undoable operations.

Key components:

Command: Object with execute() (and optionally undo()).
Invoker: Triggers commands (e.g., a button, a queue processor).
Receiver: The actual object that performs the work.

In Python, commands can be simple callables (functions, lambdas) or class instances for complex cases like undo/redo.

Pseudo Code

1. Define Command objects with execute() and undo() methods
2. Invoker stores and executes commands
3. Receiver performs the actual work
4. History stack enables undo/redo
5. Pythonic: use callables for simple commands

Code

from abc import ABC, abstractmethod
from typing import Any

# Command interface
class Command(ABC):
    @abstractmethod
    def execute(self) -> None: ...
    @abstractmethod
    def undo(self) -> None: ...

# Receiver: the actual text document
class TextDocument:
    def __init__(self):
        self.content = ""

    def insert(self, text: str, position: int) -> None:
        self.content = self.content[:position] + text + self.content[position:]

    def delete(self, position: int, length: int) -> str:
        deleted = self.content[position:position + length]
        self.content = self.content[:position] + self.content[position + length:]
        return deleted

# Concrete commands
class InsertCommand(Command):
    def __init__(self, document: TextDocument, text: str, position: int):
        self.document = document
        self.text = text
        self.position = position

    def execute(self) -> None:
        self.document.insert(self.text, self.position)

    def undo(self) -> None:
        self.document.delete(self.position, len(self.text))

class DeleteCommand(Command):
    def __init__(self, document: TextDocument, position: int, length: int):
        self.document = document
        self.position = position
        self.length = length
        self._deleted_text = ""

    def execute(self) -> None:
        self._deleted_text = self.document.delete(self.position, self.length)

    def undo(self) -> None:
        self.document.insert(self._deleted_text, self.position)

# Invoker with undo/redo
class Editor:
    def __init__(self):
        self._history: list[Command] = []
        self._redo_stack: list[Command] = []

    def execute(self, command: Command) -> None:
        command.execute()
        self._history.append(command)
        self._redo_stack.clear()

    def undo(self) -> None:
        if self._history:
            command = self._history.pop()
            command.undo()
            self._redo_stack.append(command)

    def redo(self) -> None:
        if self._redo_stack:
            command = self._redo_stack.pop()
            command.execute()
            self._history.append(command)

# Usage
doc = TextDocument()
editor = Editor()

editor.execute(InsertCommand(doc, "Hello ", 0))
print(doc.content)  # "Hello "

editor.execute(InsertCommand(doc, "World!", 6))
print(doc.content)  # "Hello World!"

editor.undo()
print(doc.content)  # "Hello "

editor.redo()
print(doc.content)  # "Hello World!"

editor.execute(DeleteCommand(doc, 5, 1))
print(doc.content)  # "HelloWorld!"

editor.undo()
print(doc.content)  # "Hello World!"

Hello
Hello World!
Hello
Hello World!
HelloWorld!
Hello World!

Key Points

•Command encapsulates action + undo as an object
•Invoker stores command history for undo/redo
•Commands capture all data needed to execute AND reverse the operation
•Delete commands must save deleted content for undo
•Clear redo stack when a new command is executed

Gotchas

•Undo requires storing enough state to reverse the operation
•Complex operations may need composite commands (macro commands)
•Memory usage grows with history; consider limiting history size

Command encapsulates an action as an object with execute() and undo(). An invoker stores command history for undo/redo. Commands must capture all data needed to reverse the operation.

•Command = execute + undo; Invoker = history stack
•Commands capture data needed to reverse operations

class InsertCommand:
    def __init__(self, doc, text, pos):
        self.doc, self.text, self.pos = doc, text, pos
    def execute(self):
        self.doc.insert(self.text, self.pos)
    def undo(self):
        self.doc.delete(self.pos, len(self.text))

# Invoker tracks history
class Editor:
    def __init__(self):
        self._history = []
    def execute(self, cmd):
        cmd.execute()
        self._history.append(cmd)
    def undo(self):
        if self._history:
            self._history.pop().undo()

Delete commands must store what was deleted for undo

Question 8 / 18

How do you implement the Template Method pattern in Python?

The Template Method pattern defines the skeleton of an algorithm in a base class, deferring some steps to subclasses. Subclasses override specific steps without changing the overall structure.

This is naturally supported in Python through abstract methods and inheritance.

Pseudo Code

1. Base class defines the template method (algorithm skeleton)
2. Template method calls abstract hook methods
3. Subclasses implement the hook methods
4. Template method is NOT overridden; only hooks are

Code

from abc import ABC, abstractmethod

class DataPipeline(ABC):
    """Template: extract -> transform -> load."""

    def run(self) -> dict:
        """Template method - defines the algorithm skeleton."""
        raw_data = self.extract()
        cleaned = self.transform(raw_data)
        result = self.load(cleaned)
        self.notify(result)  # Optional hook with default
        return result

    @abstractmethod
    def extract(self) -> list:
        """Step 1: Extract data from source."""
        ...

    @abstractmethod
    def transform(self, data: list) -> list:
        """Step 2: Transform/clean data."""
        ...

    @abstractmethod
    def load(self, data: list) -> dict:
        """Step 3: Load data to destination."""
        ...

    def notify(self, result: dict) -> None:
        """Optional hook (not abstract, has default)."""
        print(f"Pipeline complete: {result.get('count', 0)} records")

class CSVToDatabase(DataPipeline):
    def extract(self) -> list:
        print("Reading CSV file...")
        return [{'name': 'Alice', 'age': '30'}, {'name': 'Bob', 'age': '25'}]

    def transform(self, data: list) -> list:
        print("Converting ages to int...")
        return [{'name': d['name'], 'age': int(d['age'])} for d in data]

    def load(self, data: list) -> dict:
        print(f"Inserting {len(data)} records into database...")
        return {'count': len(data), 'status': 'success'}

class APIToFile(DataPipeline):
    def extract(self) -> list:
        print("Fetching from API...")
        return [{'id': 1, 'value': 'data'}]

    def transform(self, data: list) -> list:
        print("Formatting for file...")
        return [f"{d['id']},{d['value']}" for d in data]

    def load(self, data: list) -> dict:
        print(f"Writing {len(data)} lines to file...")
        return {'count': len(data), 'status': 'success'}

    def notify(self, result: dict) -> None:
        print(f"Sending Slack notification: {result}")

# Same template, different implementations
pipeline1 = CSVToDatabase()
pipeline1.run()

pipeline2 = APIToFile()
pipeline2.run()

Reading CSV file...
Converting ages to int...
Inserting 2 records into database...
Pipeline complete: 2 records
Fetching from API...
Formatting for file...
Writing 1 lines to file...
Sending Slack notification: {'count': 1, 'status': 'success'}

Key Points

•Template method in base class defines the algorithm skeleton
•Abstract methods are mandatory steps subclasses must implement
•Hook methods have default implementations that subclasses may override
•Template method itself is NOT abstract (subclasses do not override it)
•Follows 'Hollywood Principle': don't call us, we'll call you

Gotchas

•Overriding the template method defeats the purpose of the pattern
•Too many abstract methods make subclasses burdensome; use hooks with defaults
•In Python, consider composition (Strategy) over inheritance (Template Method) for flexibility

Template Method defines an algorithm skeleton in a base class with abstract steps that subclasses implement. The skeleton method is not overridden; only the individual steps are.

•Base class defines skeleton; subclasses fill in the steps
•Template method is final (not overridden)

class Pipeline(ABC):
    def run(self):  # Template method (not overridden)
        data = self.extract()
        data = self.transform(data)
        self.load(data)

    @abstractmethod
    def extract(self): ...
    @abstractmethod
    def transform(self, data): ...
    @abstractmethod
    def load(self, data): ...

class CSVPipeline(Pipeline):
    def extract(self): return read_csv()
    def transform(self, data): return clean(data)
    def load(self, data): write_db(data)

Prefer Strategy (composition) over Template Method (inheritance) for flexibility

Question 9 / 18

How do you implement the Adapter pattern in Python?

The Adapter pattern converts the interface of one class to the interface expected by clients. It lets classes work together that otherwise could not due to incompatible interfaces.

Two approaches:

Object adapter (composition): Wraps the adaptee in a new class.
Class adapter (inheritance): Inherits from both the target and adaptee.

In Python, the object adapter (composition) is preferred because Python supports duck typing -- you just need to match the expected interface.

Pseudo Code

1. Client expects a specific interface (e.g., method .read())
2. Adaptee has a different interface (e.g., method .fetch())
3. Adapter wraps the adaptee, translating .read() to .fetch()
4. Client uses the adapter without knowing about the adaptee

Code

# Existing system expects this interface
class MediaPlayer:
    def play(self, filename: str) -> str:
        return f"Playing {filename}"

# Third-party library with different interface
class VLCPlayer:
    def play_media(self, file_path: str, volume: int = 100) -> str:
        return f"VLC playing {file_path} at volume {volume}"

class FFmpegPlayer:
    def stream(self, source: str) -> str:
        return f"FFmpeg streaming {source}"

# Adapters translate interfaces
class VLCAdapter:
    def __init__(self, vlc: VLCPlayer):
        self._vlc = vlc

    def play(self, filename: str) -> str:
        return self._vlc.play_media(filename)

class FFmpegAdapter:
    def __init__(self, ffmpeg: FFmpegPlayer):
        self._ffmpeg = ffmpeg

    def play(self, filename: str) -> str:
        return self._ffmpeg.stream(filename)

# Client code works with any player that has .play()
def play_song(player, filename: str) -> None:
    print(player.play(filename))

play_song(MediaPlayer(), "song.mp3")
play_song(VLCAdapter(VLCPlayer()), "song.mp3")
play_song(FFmpegAdapter(FFmpegPlayer()), "song.mp3")

# Real-world: adapting different database interfaces
class PostgresDB:
    def execute_query(self, sql: str) -> list:
        return [{'result': 'postgres data'}]

class MongoDB:
    def find(self, collection: str, query: dict) -> list:
        return [{'result': 'mongo data'}]

# Unified interface
class DatabaseAdapter:
    def __init__(self, db):
        self._db = db

    def query(self, query_str: str) -> list:
        if isinstance(self._db, PostgresDB):
            return self._db.execute_query(query_str)
        elif isinstance(self._db, MongoDB):
            return self._db.find('default', {'raw': query_str})
        raise TypeError(f"Unsupported database: {type(self._db)}")

db = DatabaseAdapter(PostgresDB())
result = db.query('SELECT * FROM users')

Playing song.mp3
VLC playing song.mp3 at volume 100
FFmpeg streaming song.mp3

Key Points

•Adapter translates one interface to another expected by the client
•Object adapter (composition) is preferred in Python over class adapter (inheritance)
•Duck typing means you just need to match the expected methods
•Useful for integrating third-party libraries with incompatible interfaces
•Keeps client code unchanged when swapping underlying implementations

Gotchas

•Adapters add a layer of indirection; too many adapters can obscure the code
•isinstance checks in the adapter defeat the purpose; prefer one adapter per adaptee
•If you control both interfaces, refactoring is better than adapting

Adapter wraps an object with an incompatible interface, translating method calls to match what the client expects. Use composition (object adapter) in Python. Duck typing makes this natural -- just implement the expected methods.

•Wraps incompatible interface to match expected one
•Composition preferred; duck typing makes it natural

class VLCAdapter:
    def __init__(self, vlc):
        self._vlc = vlc
    def play(self, filename):  # Expected interface
        return self._vlc.play_media(filename)  # Adapted call

# Client code works with any object that has .play()
player = VLCAdapter(VLCPlayer())
player.play('song.mp3')

One adapter per adaptee; avoid isinstance checks inside adapters

Question 10 / 18

How do you implement the Facade pattern in Python?

The Facade pattern provides a simplified interface to a complex subsystem. Instead of interacting with many classes and methods, clients use a single facade with high-level methods.

Facades do not add new functionality; they organize existing functionality into a simpler API. The subsystem classes are still accessible for advanced use.

Pseudo Code

1. Identify a complex subsystem with many classes
2. Create a Facade class with simple high-level methods
3. Facade delegates to subsystem classes internally
4. Clients use the facade; advanced users access subsystem directly

Code

# Complex subsystem classes
class VideoDecoder:
    def decode(self, filename: str) -> bytes:
        print(f"Decoding video: {filename}")
        return b"decoded_video"

class AudioDecoder:
    def decode(self, filename: str) -> bytes:
        print(f"Decoding audio: {filename}")
        return b"decoded_audio"

class VideoRenderer:
    def render(self, video_data: bytes, resolution: str) -> bytes:
        print(f"Rendering video at {resolution}")
        return b"rendered"

class AudioMixer:
    def mix(self, audio_data: bytes, volume: float) -> bytes:
        print(f"Mixing audio at volume {volume}")
        return b"mixed"

class FileWriter:
    def write(self, filename: str, data: bytes) -> None:
        print(f"Writing to {filename}")

# Facade: simple interface for video conversion
class VideoConverter:
    """Facade that simplifies video conversion."""

    def __init__(self):
        self._video_decoder = VideoDecoder()
        self._audio_decoder = AudioDecoder()
        self._renderer = VideoRenderer()
        self._mixer = AudioMixer()
        self._writer = FileWriter()

    def convert(self, input_file: str, output_file: str,
                resolution: str = "1080p", volume: float = 1.0) -> None:
        """Convert a video file with one simple call."""
        video = self._video_decoder.decode(input_file)
        audio = self._audio_decoder.decode(input_file)
        rendered = self._renderer.render(video, resolution)
        mixed = self._mixer.mix(audio, volume)
        self._writer.write(output_file, rendered + mixed)
        print(f"Conversion complete: {output_file}")

# Client uses the simple facade
converter = VideoConverter()
converter.convert("input.avi", "output.mp4", resolution="720p")
# vs. manually calling 5 subsystem classes

# Real-world: email sending facade
class SMTPConnection:
    def connect(self, host: str, port: int) -> None: ...
    def authenticate(self, user: str, password: str) -> None: ...
    def send(self, data: bytes) -> None: ...
    def disconnect(self) -> None: ...

class EmailComposer:
    def compose(self, to: str, subject: str, body: str) -> bytes: ...

class EmailFacade:
    def __init__(self, host: str, port: int, user: str, password: str):
        self._host = host
        self._port = port
        self._user = user
        self._password = password

    def send_email(self, to: str, subject: str, body: str) -> None:
        composer = EmailComposer()
        data = composer.compose(to, subject, body)

        conn = SMTPConnection()
        conn.connect(self._host, self._port)
        conn.authenticate(self._user, self._password)
        conn.send(data)
        conn.disconnect()

# One-liner instead of 6 steps
# email = EmailFacade('smtp.gmail.com', 587, 'user', 'pass')
# email.send_email('bob@example.com', 'Hello', 'Hi Bob!')

Decoding video: input.avi
Decoding audio: input.avi
Rendering video at 720p
Mixing audio at volume 1.0
Writing to output.mp4
Conversion complete: output.mp4

Key Points

•Facade provides a simple interface to a complex subsystem
•Does not add new functionality; organizes existing functionality
•Subsystem classes remain accessible for advanced use
•Common in libraries: high-level API wraps low-level details
•Reduces coupling between client and subsystem

Gotchas

•A facade that does too much becomes a 'god object'; keep it focused
•Facades should not prevent access to the underlying subsystem
•If the facade grows too large, consider splitting into multiple facades

Facade provides a simple interface to a complex subsystem. One high-level method delegates to many internal classes. Does not add functionality; simplifies the API.

•Simple interface to complex subsystem; delegates internally
•Subsystem still accessible for advanced use

class VideoConverter:  # Facade
    def __init__(self):
        self._decoder = VideoDecoder()
        self._renderer = VideoRenderer()
        self._writer = FileWriter()

    def convert(self, input_file, output_file):
        data = self._decoder.decode(input_file)
        rendered = self._renderer.render(data, '1080p')
        self._writer.write(output_file, rendered)

# Simple: converter.convert('in.avi', 'out.mp4')

Do not make the facade a god object; keep it focused

Question 11 / 18

How do you implement the Repository pattern in Python?

The Repository pattern abstracts data access behind a collection-like interface, separating business logic from data storage. The domain layer works with repository interfaces, not database queries directly.

Benefits:

Swap data sources (SQLAlchemy, in-memory, API) without changing business logic.
Easy to mock in tests.
Centralized query logic.

In Python, use Protocol or ABC to define the repository interface, then implement concrete repositories for different backends.

Pseudo Code

1. Define a Repository interface (Protocol or ABC)
2. Implement concrete repositories (SQLAlchemy, in-memory, etc.)
3. Business logic depends on the interface, not the implementation
4. Inject the repository into services/controllers
5. Use in-memory repository for testing

Code

from abc import ABC, abstractmethod
from typing import Protocol
from dataclasses import dataclass

@dataclass
class User:
    id: int | None
    name: str
    email: str

# Repository interface
class UserRepository(Protocol):
    def get_by_id(self, user_id: int) -> User | None: ...
    def get_by_email(self, email: str) -> User | None: ...
    def get_all(self) -> list[User]: ...
    def save(self, user: User) -> User: ...
    def delete(self, user_id: int) -> None: ...

# In-memory implementation (great for testing)
class InMemoryUserRepository:
    def __init__(self):
        self._users: dict[int, User] = {}
        self._next_id = 1

    def get_by_id(self, user_id: int) -> User | None:
        return self._users.get(user_id)

    def get_by_email(self, email: str) -> User | None:
        for user in self._users.values():
            if user.email == email:
                return user
        return None

    def get_all(self) -> list[User]:
        return list(self._users.values())

    def save(self, user: User) -> User:
        if user.id is None:
            user.id = self._next_id
            self._next_id += 1
        self._users[user.id] = user
        return user

    def delete(self, user_id: int) -> None:
        self._users.pop(user_id, None)

# SQLAlchemy implementation
class SQLAlchemyUserRepository:
    def __init__(self, session):
        self._session = session

    def get_by_id(self, user_id: int) -> User | None:
        row = self._session.query(UserModel).get(user_id)
        return self._to_entity(row) if row else None

    def get_by_email(self, email: str) -> User | None:
        row = self._session.query(UserModel).filter_by(email=email).first()
        return self._to_entity(row) if row else None

    def get_all(self) -> list[User]:
        rows = self._session.query(UserModel).all()
        return [self._to_entity(r) for r in rows]

    def save(self, user: User) -> User:
        model = UserModel(id=user.id, name=user.name, email=user.email)
        self._session.merge(model)
        self._session.flush()
        user.id = model.id
        return user

    def delete(self, user_id: int) -> None:
        self._session.query(UserModel).filter_by(id=user_id).delete()

    @staticmethod
    def _to_entity(row) -> User:
        return User(id=row.id, name=row.name, email=row.email)

# Service layer uses the repository interface
class UserService:
    def __init__(self, repo: UserRepository):
        self._repo = repo

    def register(self, name: str, email: str) -> User:
        if self._repo.get_by_email(email):
            raise ValueError(f"Email {email} already registered")
        user = User(id=None, name=name, email=email)
        return self._repo.save(user)

# Production
# service = UserService(SQLAlchemyUserRepository(session))

# Testing
service = UserService(InMemoryUserRepository())
user = service.register('Alice', 'alice@example.com')
print(user)  # User(id=1, name='Alice', email='alice@example.com')

User(id=1, name='Alice', email='alice@example.com')

Key Points

•Repository abstracts data access behind a collection-like interface
•Use Protocol or ABC to define the interface; implement per backend
•InMemoryRepository for testing; SQLAlchemy/API repositories for production
•Business logic depends on the interface, making it testable and backend-agnostic
•Centralizes query logic in one place

Gotchas

•Repositories should return domain objects, not ORM models (keep layers separate)
•Do not put business logic in repositories; keep them focused on data access
•Too many custom query methods can bloat the repository; consider a specification pattern

Repository abstracts data access behind a collection-like interface (get, save, delete). Define with Protocol/ABC, implement per backend (SQLAlchemy, in-memory). Services depend on the interface, not the implementation.

•Interface separates business logic from data storage
•In-memory implementation for tests; real DB for production

class UserRepository(Protocol):
    def get_by_id(self, id: int) -> User | None: ...
    def save(self, user: User) -> User: ...
    def delete(self, id: int) -> None: ...

class InMemoryUserRepo:
    def __init__(self):
        self._users = {}
    def get_by_id(self, id):
        return self._users.get(id)
    def save(self, user):
        self._users[user.id] = user
        return user

service = UserService(InMemoryUserRepo())  # Easy to test

Return domain objects, not ORM models

Question 12 / 18

How do you implement Dependency Injection in Python?

Dependency Injection (DI) is a technique where an object receives its dependencies from the outside rather than creating them itself. This follows the Dependency Inversion Principle (the 'D' in SOLID): depend on abstractions, not concretions.

DI methods:

Constructor injection: Pass dependencies via __init__.
Method injection: Pass dependencies as method parameters.
Setter injection: Set dependencies via setter methods.

Python does not need a DI framework for most cases; constructor injection is simple and effective.

Pseudo Code

1. Define interfaces (Protocol/ABC) for dependencies
2. Pass concrete implementations via constructor
3. Classes depend on interfaces, not implementations
4. In production, wire up real implementations
5. In tests, inject mocks or in-memory implementations

Code

from typing import Protocol

# Interfaces
class EmailSender(Protocol):
    def send(self, to: str, subject: str, body: str) -> None: ...

class Logger(Protocol):
    def info(self, message: str) -> None: ...
    def error(self, message: str) -> None: ...

class UserRepository(Protocol):
    def save(self, user: dict) -> dict: ...
    def get_by_email(self, email: str) -> dict | None: ...

# Service with injected dependencies
class UserService:
    def __init__(self, repo: UserRepository, email: EmailSender, logger: Logger):
        self._repo = repo
        self._email = email
        self._logger = logger

    def register(self, name: str, email: str) -> dict:
        self._logger.info(f"Registering user: {email}")

        if self._repo.get_by_email(email):
            self._logger.error(f"Email already exists: {email}")
            raise ValueError("Email already registered")

        user = self._repo.save({'name': name, 'email': email})
        self._email.send(email, "Welcome!", f"Hi {name}, welcome!")
        self._logger.info(f"User registered: {user}")
        return user

# Production implementations
class SMTPEmailSender:
    def send(self, to: str, subject: str, body: str) -> None:
        print(f"SMTP: Sending '{subject}' to {to}")

class ConsoleLogger:
    def info(self, message: str) -> None:
        print(f"[INFO] {message}")
    def error(self, message: str) -> None:
        print(f"[ERROR] {message}")

class SQLUserRepository:
    def save(self, user: dict) -> dict:
        user['id'] = 1
        return user
    def get_by_email(self, email: str) -> dict | None:
        return None

# Wire up dependencies
service = UserService(
    repo=SQLUserRepository(),
    email=SMTPEmailSender(),
    logger=ConsoleLogger(),
)
service.register('Alice', 'alice@example.com')

# Test with mocks (no framework needed)
class MockEmailSender:
    def __init__(self):
        self.sent = []
    def send(self, to, subject, body):
        self.sent.append((to, subject, body))

class MockRepo:
    def __init__(self):
        self.users = {}
    def save(self, user):
        user['id'] = len(self.users) + 1
        self.users[user['email']] = user
        return user
    def get_by_email(self, email):
        return self.users.get(email)

# Test
mock_email = MockEmailSender()
mock_repo = MockRepo()
test_service = UserService(mock_repo, mock_email, ConsoleLogger())
test_service.register('Test', 'test@example.com')
assert len(mock_email.sent) == 1
assert mock_email.sent[0][0] == 'test@example.com'

[INFO] Registering user: alice@example.com
SMTP: Sending 'Welcome!' to alice@example.com
[INFO] User registered: {'name': 'Alice', 'email': 'alice@example.com', 'id': 1}
[INFO] Registering user: test@example.com
[INFO] User registered: {'name': 'Test', 'email': 'test@example.com', 'id': 1}

Key Points

•Constructor injection: pass dependencies via __init__ (most common)
•Depend on abstractions (Protocol/ABC), not concrete classes
•No DI framework needed in Python for most cases
•In tests, inject mocks or fakes instead of real implementations
•DI makes code testable, flexible, and follows SOLID principles

Gotchas

•Too many constructor parameters suggest the class has too many responsibilities
•DI frameworks (inject, dependency-injector) add complexity; use them only for large apps
•Do not inject everything; only inject things that have alternative implementations

Pass dependencies via __init__ instead of creating them inside the class. Depend on interfaces (Protocol), not concrete classes. In tests, inject mocks. No framework needed in Python.

•Constructor injection; depend on interfaces, not implementations
•Inject mocks for testing; no framework needed

class UserService:
    def __init__(self, repo: UserRepository, email: EmailSender):
        self._repo = repo
        self._email = email

# Production
service = UserService(SQLRepo(), SMTPEmail())

# Testing
service = UserService(MockRepo(), MockEmail())

Too many injected deps = too many responsibilities (split the class)

Question 13 / 18

What are the SOLID principles and how do they apply in Python?

SOLID is a set of five design principles for writing maintainable, flexible code:

S - Single Responsibility Principle (SRP): A class should have only one reason to change.
O - Open/Closed Principle (OCP): Open for extension, closed for modification.
L - Liskov Substitution Principle (LSP): Subtypes must be substitutable for their base types.
I - Interface Segregation Principle (ISP): Many specific interfaces are better than one general-purpose interface.
D - Dependency Inversion Principle (DIP): Depend on abstractions, not concretions.

Pseudo Code

S: One class = one responsibility
O: Add behavior by extending, not modifying
L: Subclasses can replace parent without breaking
I: Small, focused interfaces instead of fat ones
D: Depend on abstractions (Protocol/ABC)

Code

from abc import ABC, abstractmethod
from typing import Protocol

# S - Single Responsibility
# BAD: one class does everything
class BadUserManager:
    def create_user(self, data): ...      # Business logic
    def save_to_db(self, user): ...       # Persistence
    def send_welcome_email(self, user): ...  # Email
    def generate_report(self, users): ...    # Reporting

# GOOD: separate responsibilities
class UserService:
    def create_user(self, data): ...

class UserRepository:
    def save(self, user): ...

class EmailService:
    def send_welcome(self, user): ...

# O - Open/Closed
# BAD: modify existing code for each new shape
def bad_area(shape):
    if shape.type == 'circle':
        return 3.14 * shape.radius ** 2
    elif shape.type == 'rectangle':  # Must modify for each new shape
        return shape.width * shape.height

# GOOD: extend by adding new classes
class Shape(Protocol):
    def area(self) -> float: ...

class Circle:
    def __init__(self, radius: float):
        self.radius = radius
    def area(self) -> float:
        return 3.14 * self.radius ** 2

class Rectangle:
    def __init__(self, width: float, height: float):
        self.width = width
        self.height = height
    def area(self) -> float:
        return self.width * self.height

def total_area(shapes: list[Shape]) -> float:
    return sum(s.area() for s in shapes)  # No modification needed for new shapes

# L - Liskov Substitution
# BAD: Square breaks Rectangle's contract
class BadRectangle:
    def __init__(self, w, h):
        self.width = w
        self.height = h

class BadSquare(BadRectangle):  # Violates LSP
    def __init__(self, side):
        super().__init__(side, side)
    # Setting width should not change height, but in a square it must

# GOOD: separate classes, shared interface
class Shape(Protocol):
    def area(self) -> float: ...

# I - Interface Segregation
# BAD: fat interface
class BadWorker(ABC):
    @abstractmethod
    def work(self): ...
    @abstractmethod
    def eat(self): ...   # Robots don't eat!

# GOOD: small, focused interfaces
class Workable(Protocol):
    def work(self) -> None: ...

class Feedable(Protocol):
    def eat(self) -> None: ...

class Human:
    def work(self) -> None: print("Working")
    def eat(self) -> None: print("Eating")

class Robot:
    def work(self) -> None: print("Working")
    # No eat() needed

# D - Dependency Inversion
# BAD: depends on concrete class
class BadNotifier:
    def __init__(self):
        self.sender = SMTPSender()  # Concrete dependency

# GOOD: depends on abstraction
class Sender(Protocol):
    def send(self, to: str, msg: str) -> None: ...

class Notifier:
    def __init__(self, sender: Sender):  # Depends on abstraction
        self.sender = sender

Key Points

•SRP: Split classes by responsibility (persistence, business logic, email, etc.)
•OCP: Use polymorphism (Protocol/ABC) to add behavior without modifying existing code
•LSP: Subclasses must honor the parent's contract (pre/post conditions)
•ISP: Use Protocol for small, focused interfaces; classes implement only what they need
•DIP: Inject dependencies via constructor; depend on Protocol, not concrete classes

Gotchas

•Over-applying SOLID to simple code creates unnecessary complexity
•Python's duck typing naturally supports ISP (no need to formally implement interfaces)
•SRP does not mean one method per class; it means one reason to change

Single responsibility (one reason to change), Open/closed (extend, don't modify), Liskov substitution (subtypes replaceable), Interface segregation (small interfaces), Dependency inversion (depend on abstractions). Python's Protocol and duck typing make these natural.

•SOLID principles guide maintainable, flexible design
•Python's duck typing and Protocol make ISP and DIP natural

# SRP: separate classes per concern
class UserService:     ...  # Business logic
class UserRepository:  ...  # Data access
class EmailService:    ...  # Email

# OCP: add new shapes without modifying total_area
class Shape(Protocol):
    def area(self) -> float: ...

# DIP: depend on Protocol, not concrete class
class Notifier:
    def __init__(self, sender: Sender): ...

Over-engineering: apply SOLID pragmatically, not dogmatically

Question 14 / 18

How do you implement the Proxy pattern in Python?

The Proxy pattern provides a surrogate or placeholder for another object to control access to it. The proxy has the same interface as the real object.

Types of proxies:

Virtual proxy (lazy loading): Delays expensive object creation until needed.
Protection proxy (access control): Checks permissions before delegating.
Caching proxy: Caches results of expensive operations.
Logging proxy: Logs access to the real object.

Pseudo Code

1. Proxy has same interface as the real subject
2. Proxy holds a reference to the real subject
3. Proxy intercepts calls, adds behavior, then delegates
4. Client cannot tell the difference between proxy and real object

Code

from typing import Protocol
import time

# Subject interface
class Database(Protocol):
    def query(self, sql: str) -> list: ...

# Real subject (expensive)
class RealDatabase:
    def __init__(self, connection_string: str):
        print(f"Connecting to {connection_string}...")
        time.sleep(0.1)  # Simulate slow connection
        self._conn = connection_string

    def query(self, sql: str) -> list:
        print(f"Executing: {sql}")
        return [{'id': 1, 'name': 'Alice'}]

# Virtual proxy (lazy loading)
class LazyDatabase:
    def __init__(self, connection_string: str):
        self._connection_string = connection_string
        self._db: RealDatabase | None = None

    def _get_db(self) -> RealDatabase:
        if self._db is None:
            self._db = RealDatabase(self._connection_string)
        return self._db

    def query(self, sql: str) -> list:
        return self._get_db().query(sql)

# No connection made yet
db = LazyDatabase('postgres://...')
print("DB object created, no connection yet")
# Connection made on first query
result = db.query('SELECT * FROM users')

# Caching proxy
class CachingDatabase:
    def __init__(self, db: Database):
        self._db = db
        self._cache: dict[str, list] = {}

    def query(self, sql: str) -> list:
        if sql in self._cache:
            print(f"Cache hit: {sql}")
            return self._cache[sql]
        print(f"Cache miss: {sql}")
        result = self._db.query(sql)
        self._cache[sql] = result
        return result

    def invalidate(self, sql: str | None = None) -> None:
        if sql:
            self._cache.pop(sql, None)
        else:
            self._cache.clear()

# Protection proxy
class ProtectedDatabase:
    def __init__(self, db: Database, allowed_users: set[str]):
        self._db = db
        self._allowed = allowed_users
        self._current_user: str | None = None

    def login(self, username: str) -> None:
        self._current_user = username

    def query(self, sql: str) -> list:
        if self._current_user not in self._allowed:
            raise PermissionError(f"User '{self._current_user}' not authorized")
        return self._db.query(sql)

# Stack proxies
real_db = RealDatabase('postgres://...')
cached = CachingDatabase(real_db)
protected = ProtectedDatabase(cached, {'admin', 'analyst'})

protected.login('admin')
result = protected.query('SELECT * FROM users')  # Cache miss
result = protected.query('SELECT * FROM users')  # Cache hit

DB object created, no connection yet
Connecting to postgres://......
Executing: SELECT * FROM users
Connecting to postgres://......
Cache miss: SELECT * FROM users
Executing: SELECT * FROM users
Cache hit: SELECT * FROM users

Key Points

•Proxy has the same interface as the real object (transparent to client)
•Virtual proxy delays creation; caching proxy stores results; protection proxy checks access
•Proxies can be stacked (caching wraps real, protection wraps caching)
•Python's __getattr__ can create generic proxies that delegate all attribute access
•Useful for lazy loading, access control, logging, and caching

Gotchas

•Proxy must faithfully replicate the interface; missing methods break transparency
•Caching proxies must handle cache invalidation (stale data)
•Lazy proxies can surprise with delayed initialization side effects

Proxy wraps a real object with the same interface, adding behavior like lazy loading, caching, or access control. Client cannot tell proxy from real object. Proxies can be stacked.

•Same interface as real object; adds lazy/cache/access control behavior
•Stackable: CachingDB wraps LazyDB wraps RealDB

class LazyDB:
    def __init__(self, conn_str):
        self._conn_str = conn_str
        self._db = None
    def query(self, sql):
        if self._db is None:
            self._db = RealDB(self._conn_str)  # Lazy init
        return self._db.query(sql)

class CachingDB:
    def __init__(self, db):
        self._db, self._cache = db, {}
    def query(self, sql):
        if sql not in self._cache:
            self._cache[sql] = self._db.query(sql)
        return self._cache[sql]

Cache invalidation is the hardest part of caching proxies

Question 15 / 18

How do you implement the State pattern in Python?

The State pattern allows an object to alter its behavior when its internal state changes. The object appears to change its class. Instead of large if/elif chains checking state, each state is a separate class with its own behavior.

Pseudo Code

1. Define a State interface with action methods
2. Create concrete state classes implementing the interface
3. Context holds a reference to the current state
4. State transitions change the context's state object
5. Actions are delegated to the current state

Code

from abc import ABC, abstractmethod

# State interface
class OrderState(ABC):
    @abstractmethod
    def process(self, order: 'Order') -> str: ...
    @abstractmethod
    def cancel(self, order: 'Order') -> str: ...
    @abstractmethod
    def ship(self, order: 'Order') -> str: ...

# Concrete states
class PendingState(OrderState):
    def process(self, order: 'Order') -> str:
        order.state = ProcessingState()
        return "Order is now being processed"

    def cancel(self, order: 'Order') -> str:
        order.state = CancelledState()
        return "Order cancelled"

    def ship(self, order: 'Order') -> str:
        return "Cannot ship: order is not yet processed"

class ProcessingState(OrderState):
    def process(self, order: 'Order') -> str:
        return "Order is already being processed"

    def cancel(self, order: 'Order') -> str:
        order.state = CancelledState()
        return "Order cancelled during processing"

    def ship(self, order: 'Order') -> str:
        order.state = ShippedState()
        return "Order has been shipped!"

class ShippedState(OrderState):
    def process(self, order: 'Order') -> str:
        return "Cannot process: order already shipped"

    def cancel(self, order: 'Order') -> str:
        return "Cannot cancel: order already shipped"

    def ship(self, order: 'Order') -> str:
        return "Order is already shipped"

class CancelledState(OrderState):
    def process(self, order: 'Order') -> str:
        return "Cannot process: order is cancelled"

    def cancel(self, order: 'Order') -> str:
        return "Order is already cancelled"

    def ship(self, order: 'Order') -> str:
        return "Cannot ship: order is cancelled"

# Context
class Order:
    def __init__(self, order_id: int):
        self.order_id = order_id
        self.state: OrderState = PendingState()

    def process(self) -> str:
        return self.state.process(self)

    def cancel(self) -> str:
        return self.state.cancel(self)

    def ship(self) -> str:
        return self.state.ship(self)

    @property
    def status(self) -> str:
        return type(self.state).__name__.replace('State', '')

# Usage
order = Order(1)
print(order.status)      # Pending
print(order.ship())      # Cannot ship: order is not yet processed
print(order.process())   # Order is now being processed
print(order.status)      # Processing
print(order.ship())      # Order has been shipped!
print(order.status)      # Shipped
print(order.cancel())    # Cannot cancel: order already shipped

Pending
Cannot ship: order is not yet processed
Order is now being processed
Processing
Order has been shipped!
Shipped
Cannot cancel: order already shipped

Key Points

•Each state is a separate class with its own behavior for each action
•Context delegates actions to the current state object
•State transitions happen by replacing the state object on the context
•Eliminates complex if/elif state-checking code
•Each state controls which transitions are valid

Gotchas

•Many states with many actions creates many small classes (can feel verbose)
•State objects should not hold mutable data; they should be stateless or shared
•For simple state machines, an enum with a dict of transitions may be simpler

State pattern: each state is a class with action methods. The context delegates actions to its current state. Transitions swap the state object. Eliminates if/elif chains for state checks.

•Each state is a class; context delegates to current state
•Transitions swap the state object

class PendingState:
    def process(self, order):
        order.state = ProcessingState()
        return "Processing"
    def cancel(self, order):
        order.state = CancelledState()
        return "Cancelled"

class Order:
    def __init__(self):
        self.state = PendingState()
    def process(self):
        return self.state.process(self)

For simple cases, an enum + dict of transitions may be cleaner

Question 16 / 18

How do you implement the Chain of Responsibility pattern in Python?

The Chain of Responsibility pattern passes a request along a chain of handlers. Each handler decides either to process the request or pass it to the next handler in the chain.

This is exactly how middleware works in web frameworks (Flask, Django) and is also used in logging handlers, validation chains, and event processing.

Pseudo Code

1. Define a Handler base with handle() and a reference to next
2. Each handler checks if it can process the request
3. If yes, process it; if no, pass to the next handler
4. Build the chain by linking handlers together

Code

from abc import ABC, abstractmethod
from typing import Any

# Abstract handler
class Handler(ABC):
    def __init__(self):
        self._next: Handler | None = None

    def set_next(self, handler: 'Handler') -> 'Handler':
        self._next = handler
        return handler  # For chaining: a.set_next(b).set_next(c)

    def handle(self, request: dict) -> str | None:
        if self._next:
            return self._next.handle(request)
        return None

# Concrete handlers
class AuthHandler(Handler):
    def handle(self, request: dict) -> str | None:
        if 'token' not in request:
            return "Error: Authentication required"
        print("Auth: Token verified")
        return super().handle(request)

class RateLimitHandler(Handler):
    def __init__(self, max_requests: int = 10):
        super().__init__()
        self._count = 0
        self._max = max_requests

    def handle(self, request: dict) -> str | None:
        self._count += 1
        if self._count > self._max:
            return "Error: Rate limit exceeded"
        print(f"RateLimit: {self._count}/{self._max}")
        return super().handle(request)

class ValidationHandler(Handler):
    def handle(self, request: dict) -> str | None:
        if 'body' not in request or not request['body']:
            return "Error: Request body is required"
        print("Validation: Body present")
        return super().handle(request)

class BusinessLogicHandler(Handler):
    def handle(self, request: dict) -> str | None:
        print(f"Processing: {request['body']}")
        return f"Success: Processed '{request['body']}'"

# Build the chain
auth = AuthHandler()
rate_limit = RateLimitHandler(max_requests=5)
validation = ValidationHandler()
logic = BusinessLogicHandler()

auth.set_next(rate_limit).set_next(validation).set_next(logic)

# Process requests through the chain
result = auth.handle({'token': 'abc', 'body': 'Hello'})
print(result)
# Auth: Token verified
# RateLimit: 1/5
# Validation: Body present
# Processing: Hello
# Success: Processed 'Hello'

# Missing token
result = auth.handle({'body': 'Hello'})
print(result)  # Error: Authentication required

# Pythonic: function-based chain (middleware pattern)
def create_chain(*handlers):
    def chain(request):
        for handler in handlers:
            result = handler(request)
            if result is not None:  # Handler consumed the request
                return result
        return None
    return chain

def check_auth(request):
    if 'token' not in request:
        return "Error: No token"
    return None  # Pass to next

def check_body(request):
    if 'body' not in request:
        return "Error: No body"
    return None

def process(request):
    return f"OK: {request['body']}"

pipeline = create_chain(check_auth, check_body, process)
print(pipeline({'token': 'x', 'body': 'data'}))  # OK: data

Auth: Token verified
RateLimit: 1/5
Validation: Body present
Processing: Hello
Success: Processed 'Hello'
Error: Authentication required
OK: data

Key Points

•Each handler decides to process or pass the request to the next handler
•set_next() returns the handler for fluent chaining: a.set_next(b).set_next(c)
•If no handler processes the request, it falls through (return None)
•Pythonic: use a list of functions instead of a class chain for simple cases
•This is the middleware pattern used in Flask, Django, and Express

Gotchas

•If no handler processes the request, the result is None; handle this case
•Long chains can be hard to debug; add logging to each handler
•Order matters: auth before validation before business logic

Chain of Responsibility passes requests through a sequence of handlers. Each handler processes or passes to the next. This is how middleware works in web frameworks. Pythonic approach: list of functions.

•Handlers process or pass; list of functions is Pythonic
•Same pattern as web middleware

# Function-based chain (Pythonic)
def auth(req):
    if 'token' not in req: return 'Unauthorized'
    return None  # pass to next

def validate(req):
    if 'body' not in req: return 'Bad Request'
    return None

def process(req):
    return f"OK: {req['body']}"

for handler in [auth, validate, process]:
    result = handler(request)
    if result is not None:
        break

Handler order matters; handle the 'no handler matched' case

Question 17 / 18

How do you combine the Decorator pattern with the Strategy pattern for flexible pipelines?

Combining patterns creates powerful, flexible architectures. A common combination is Strategy + Decorator: strategies define what to do, decorators add cross-cutting concerns (logging, timing, retry, validation) around them.

This creates a pipeline where data flows through composable, stackable layers of behavior.

Pseudo Code

1. Define a strategy interface for the core operation
2. Create concrete strategies (different algorithms)
3. Create decorator wrappers that add cross-cutting behavior
4. Stack decorators around a strategy
5. Client uses the composed pipeline transparently

Code

from typing import Callable, Any
import functools
import time

# Strategy: text processing
def uppercase(text: str) -> str:
    return text.upper()

def reverse(text: str) -> str:
    return text[::-1]

def censor(text: str) -> str:
    bad_words = {'bad', 'ugly'}
    words = text.split()
    return ' '.join('***' if w.lower() in bad_words else w for w in words)

# Decorator wrappers (cross-cutting concerns)
def with_logging(func: Callable[[str], str]) -> Callable[[str], str]:
    @functools.wraps(func)
    def wrapper(text: str) -> str:
        print(f"[LOG] Input: {text!r}")
        result = func(text)
        print(f"[LOG] Output: {result!r}")
        return result
    return wrapper

def with_timing(func: Callable[[str], str]) -> Callable[[str], str]:
    @functools.wraps(func)
    def wrapper(text: str) -> str:
        start = time.time()
        result = func(text)
        print(f"[TIME] {func.__name__}: {time.time()-start:.4f}s")
        return result
    return wrapper

def with_strip(func: Callable[[str], str]) -> Callable[[str], str]:
    @functools.wraps(func)
    def wrapper(text: str) -> str:
        return func(text.strip())
    return wrapper

# Compose: strategy + decorators
pipeline = with_logging(with_timing(with_strip(uppercase)))
result = pipeline("  hello world  ")
# [LOG] Input: '  hello world  '
# [TIME] uppercase: 0.0000s
# [LOG] Output: 'HELLO WORLD'

# Pipeline builder
class Pipeline:
    def __init__(self):
        self._steps: list[Callable[[str], str]] = []

    def add_step(self, step: Callable[[str], str]) -> 'Pipeline':
        self._steps.append(step)
        return self

    def execute(self, data: str) -> str:
        result = data
        for step in self._steps:
            result = step(result)
        return result

pipeline = (
    Pipeline()
    .add_step(str.strip)
    .add_step(censor)
    .add_step(uppercase)
    .add_step(reverse)
)

result = pipeline.execute("  This is a bad example  ")
print(result)  # ELPMAXE *** A SI SIHT

# Expected Output: (timing values are approximate)
# [LOG] Input: '  hello world  '
# [TIME] uppercase: 0.0000s
# [LOG] Output: 'HELLO WORLD'
# ELPMAXE *** A SI SIHT

Key Points

•Strategy defines the core algorithm; decorators add cross-cutting behavior
•Compose by wrapping: with_logging(with_timing(strategy))
•Pipeline builder collects steps and executes them in sequence
•Each step is a simple function, making them easy to test independently
•This pattern is used in data processing, middleware, and plugin systems

Gotchas

•Deeply nested wrappers are hard to read; use a Pipeline class for clarity
•Decorator order matters: with_logging(with_timing(f)) logs the timing, not the other way around
•Ensure all steps have compatible signatures (str -> str in this example)

Combine Strategy (what to do) with Decorator (cross-cutting concerns). Stack decorators around strategies, or use a Pipeline class that chains processing steps. Each step is a simple function.

•Strategy = core logic; Decorator = cross-cutting behavior
•Compose by wrapping or use a Pipeline builder

# Strategy functions
def uppercase(text): return text.upper()
def censor(text): return text.replace('bad', '***')

# Decorator wrapper
def with_logging(func):
    def wrapper(text):
        print(f"Input: {text}")
        result = func(text)
        print(f"Output: {result}")
        return result
    return wrapper

# Compose
pipeline = with_logging(uppercase)
pipeline("hello")  # Logged and uppercased

Input: hello
Output: HELLO

Decorator stacking order matters; innermost runs first

Question 18 / 18

When should you use inheritance vs composition in Python design?

Inheritance (is-a relationship): A subclass inherits behavior from a parent. Dog IS an Animal. Use when there is a genuine hierarchical relationship and you want to reuse a common interface.

Composition (has-a relationship): A class contains instances of other classes. Car HAS an Engine. Use when you want to combine behaviors from multiple sources.

Favor composition over inheritance is a key principle because:

Inheritance creates tight coupling between parent and child.
Changes to the parent can break all children.
Python supports single inheritance well but multiple inheritance gets complex (MRO issues).
Composition is more flexible: swap components at runtime.

When to use inheritance: Abstract base classes, frameworks requiring subclassing, clear is-a relationships. When to use composition: Combining behaviors, has-a relationships, wanting runtime flexibility.

Pseudo Code

Inheritance: class Dog(Animal) - Dog IS an Animal
Composition: class Car: engine = Engine() - Car HAS an Engine
Prefer composition for flexibility and loose coupling
Use inheritance for genuine is-a hierarchies and ABCs

Code

# BAD: Inheritance for code reuse (not an is-a relationship)
class JSONLogger:
    def log(self, message):
        import json
        print(json.dumps({'msg': message}))

class UserService(JSONLogger):  # UserService IS NOT a logger
    def create_user(self, name):
        self.log(f"Creating user: {name}")
        return {'name': name}

# GOOD: Composition
class Logger:
    def log(self, message: str) -> None:
        print(f"[LOG] {message}")

class JSONLogger:
    def log(self, message: str) -> None:
        import json
        print(json.dumps({'msg': message}))

class UserService:
    def __init__(self, logger: Logger):
        self._logger = logger  # HAS a logger

    def create_user(self, name: str) -> dict:
        self._logger.log(f"Creating user: {name}")
        return {'name': name}

# Swap logger at runtime
service = UserService(Logger())         # Console logging
service = UserService(JSONLogger())     # JSON logging

# GOOD: Inheritance for genuine is-a
from abc import ABC, abstractmethod

class Shape(ABC):
    @abstractmethod
    def area(self) -> float: ...

    @abstractmethod
    def perimeter(self) -> float: ...

class Circle(Shape):  # Circle IS a Shape
    def __init__(self, radius: float):
        self.radius = radius

    def area(self) -> float:
        return 3.14159 * self.radius ** 2

    def perimeter(self) -> float:
        return 2 * 3.14159 * self.radius

# Composition with mixins (combine behaviors)
class Serializable:
    def to_json(self) -> str:
        import json
        return json.dumps(self.__dict__)

class Validatable:
    def validate(self) -> bool:
        return all(v is not None for v in self.__dict__.values())

# Combine via composition instead of multiple inheritance
class User:
    def __init__(self, name: str, email: str):
        self.name = name
        self.email = email
        self.serializer = Serializable()
        self.validator = Validatable()

    def to_json(self) -> str:
        self.serializer.__dict__ = self.__dict__.copy()
        return self.serializer.to_json()

# Or use Protocol + delegation for maximum flexibility
class Cacheable:
    def __init__(self):
        self._cache = {}

    def get_cached(self, key: str):
        return self._cache.get(key)

    def set_cached(self, key: str, value):
        self._cache[key] = value

class ProductService:
    def __init__(self, cache: Cacheable):
        self._cache = cache

    def get_product(self, product_id: int) -> dict:
        cached = self._cache.get_cached(f"product:{product_id}")
        if cached:
            return cached
        product = {'id': product_id, 'name': 'Widget'}  # fetch from DB
        self._cache.set_cached(f"product:{product_id}", product)
        return product

Key Points

•Inheritance = is-a; Composition = has-a. Favor composition for flexibility.
•Inheritance creates tight coupling; composition allows runtime swapping
•Use inheritance for genuine hierarchies (Shape -> Circle) and ABCs
•Use composition for combining behaviors and dependencies (UserService HAS a Logger)
•Composition makes testing easier (inject mocks); inheritance makes it harder

Gotchas

•Inheriting for code reuse alone (not is-a) creates fragile, tightly coupled code
•Multiple inheritance in Python can cause MRO conflicts and diamond problems
•Composition requires more explicit delegation code but is more maintainable long-term

Inheritance = is-a (Dog IS an Animal). Composition = has-a (Car HAS an Engine). Favor composition: it is more flexible, loosely coupled, and easier to test. Use inheritance for genuine hierarchies and ABCs.

•Favor composition: more flexible, testable, loosely coupled
•Inheritance for genuine is-a; composition for has-a

# BAD: inheritance for code reuse
class UserService(Logger):  # UserService is NOT a logger
    pass

# GOOD: composition
class UserService:
    def __init__(self, logger: Logger):  # HAS a logger
        self._logger = logger

# GOOD: inheritance for is-a
class Circle(Shape):  # Circle IS a shape
    def area(self): return 3.14 * self.r ** 2

Inheriting for code reuse alone creates fragile, coupled code

Built by onllm.dev

Home GitHub Support awesomePrep