Design Patterns in Python

Creational Patterns

Patterns that deal with object creation mechanisms.

Singleton

Ensures a class has only one instance and provides a global point of access to it.

Implementation

• Naive Singleton
• Thread Safe Singleton

Use Cases

• Network manager
• Database connection pool
• Logging service
• Configuration settings
• Utility classes

Structure

• Private constructor
• Static instance variable
• Static method to get instance

Advantages

• Controlled access to sole instance
• Reduced namespace pollution
• Permits refinement of operations

Disadvantages

• Breaks single responsibility principle
• Difficult to unit test
• Global state management issues
• Can mask bad design

Factory Method

Defines an interface for creating objects but lets subclasses decide which class to instantiate.

Implementation

• Factory Method

Use Cases

• Requirements change frequently
• Dynamic switching between implementations
• Many subclass types with single instance requirement
• Hide creation logic from client

Structure

• Abstract creator class with factory method
• Concrete creators that override factory method
• Product interface
• Concrete products

Advantages

• Separation of concerns
• Open/closed principle
• Single responsibility principle
• Loose coupling

Disadvantages

• Can lead to many subclasses
• Requires inheritance

Abstract Factory

Provides an interface for creating families of related objects without specifying concrete classes.

Implementation

• Abstract Factory

Use Cases

• System independent of product creation
• Multiple families of products
• Products designed to work together
• Library provision without exposing implementation

Structure

• Abstract factory interface
• Concrete factory implementations
• Abstract product interfaces
• Concrete product families

Advantages

• One level of abstraction over factory method
• Access functionality without caring about implementation
• Isolation of concrete classes
• Easy product family switching
• Promotes consistency

Disadvantages

• Complex to implement
• Difficult to extend with new products

Builder

Separates the construction of a complex object from its representation.

Implementation

• Builder
• Builder Optimized

Use Cases

• Many parameters to initialize
• Optional parameters
• Complex object construction
• Same construction process for different representations

Structure

• Builder interface
• Concrete builders
• Director class
• Product class

Advantages

• Avoids constructor with many parameters
• Step by step construction
• Reusable construction code
• Clean and readable API

Disadvantages

• Increased code complexity
• Requires creating separate builder class

Prototype

Creates new objects by copying existing instances.

Implementation

• Prototype

Use Cases

• Creating copies of existing objects
• Objects with private or inaccessible fields
• Avoid tight coupling to concrete classes
• Testing and pre-production environments

Structure

• Prototype interface with clone method
• Concrete prototypes implementing clone
• Client that requests clones

Advantages

• Copy objects without depending on their classes
• Remove repeated initialization code
• Produce complex objects conveniently
• Alternative to inheritance

Disadvantages

• Cloning complex objects with circular references is difficult
• Deep copy vs shallow copy considerations

Structural Patterns

Patterns that deal with object composition and relationships.

Adapter

Converts the interface of a class into another interface the client expects.

Implementation

• Adapter

Use Cases

• Convert data from one format into another
• Integrate legacy code with new systems
• Use third party libraries with incompatible interfaces
• Reuse existing classes without modification

Structure

• Target interface
• Adaptee class with incompatible interface
• Adapter class implementing target interface

Advantages

• Single responsibility principle
• Open/closed principle
• Reuse existing functionality

Disadvantages

• Increased complexity
• Sometimes simpler to change the service class

Bridge

Decouples an abstraction from its implementation so both can vary independently.

Implementation

• Bridge

Use Cases

• Avoid exponential growth of inheritance tree
• Multiple orthogonal traits in classes
• Switch implementations at runtime
• Share implementation among multiple objects

Structure

• Abstraction class with reference to implementor
• Refined abstractions
• Implementor interface
• Concrete implementors

Advantages

• Convert from inheritance to composition
• Platform independent classes
• Hide implementation details from client
• Open/closed principle

Disadvantages

• Increased complexity for simple cases
• Additional indirection

Composite

Composes objects into tree structures to represent part/whole hierarchies.

Implementation

• Composite

Use Cases

• Core functionality represented as a tree
• Manipulate many objects as a single one
• File system directories
• GUI component trees

Structure

• Component interface
• Leaf class
• Composite class containing children

Advantages

• Work with complex tree structures conveniently
• Open/closed principle
• Simplify client code

Disadvantages

• Difficult to restrict component types
• Design can become overly general

Decorator

Attaches new behavior to an object without altering existing code.

Implementation

• Decorator

Use Cases

• Add behavior without subclassing
• Override behavior dynamically
• Extension by subclassing is impractical
• Wrap objects at runtime

Structure

• Component interface
• Concrete component
• Base decorator class
• Concrete decorators

Advantages

• More flexible than inheritance
• Single responsibility principle
• Combine behaviors at runtime

Disadvantages

• Difficult to remove specific wrapper
• Order of decorators matters
• Initial configuration code can look complex

Facade

Provides a simple interface to complex functionality.

Implementation

• Facade

Use Cases

• Simple interface to complex system
• Remove need for complex object/memory management
• Simplify client implementation
• Decouple subsystem from clients

Structure

• Facade class
• Subsystem classes
• Client interacting with facade

Advantages

• Isolate clients from subsystem components
• Minimize coupling
• Simplify usage

Disadvantages

• Facade can become god object
• May limit flexibility for advanced users

Flyweight

Uses sharing to support large numbers of similar objects efficiently.

Implementation

• Flyweight

Use Cases

• Large number of similar objects
• Memory constraints
• Reduce memory footprint
• Objects share intrinsic state

Structure

• Flyweight interface
• Concrete flyweight with intrinsic state
• Flyweight factory
• Client managing extrinsic state

Advantages

• Save memory when many similar objects exist
• Centralize state management
• Improved efficiency

Disadvantages

• Increased code complexity
• Trade CPU for memory
• Difficult to maintain extrinsic state

Proxy

Provides functionality before and/or after calling an object.

Implementation

• Proxy

Use Cases

• Lazy initialization
• Access control
• Logging requests
• Caching results
• Same interface as the original object

Structure

• Subject interface
• Real subject class
• Proxy class with reference to real subject

Advantages

• Control access to original object
• Manage lifecycle of service object
• Works even if service is not ready

Disadvantages

• Increased complexity
• Response delay

Behavioral Patterns

Patterns that deal with object interaction and responsibility.

Chain of Responsibility

Defines a chain of handlers to process a request, where each handler decides to process and/or pass it on.

Implementation

• Chain of Responsibility

Use Cases

• Process requests through multiple handlers
• Requests can be of different types
• Handler order matters
• Decouple sender from receiver

Structure

• Handler interface with reference to next handler
• Concrete handlers implementing processing logic
• Client initiating the request

Advantages

• Reduce coupling between sender and receiver
• Add or remove handlers dynamically
• Single responsibility principle
• Open/closed principle

Disadvantages

• Request can go unhandled
• Difficult to debug
• No guarantee of request being processed