Design Patterns Overview

Analogy categoryAnalogies

Introduction

A design pattern is a reusable, general solution to a commonly occurring problem within a given context in software design. Patterns are not finished code you can copy and paste; they are templates or blueprints that describe how to structure classes and objects to solve a recurring design problem. The idea was popularized by the book 'Design Patterns: Elements of Reusable Object-Oriented Software' (1994), written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides — collectively known as the 'Gang of Four' (GoF).

🏏

Cricket analogy: A standard fielding formation for facing a left-arm spinner isn't a fixed set of eleven specific players, it's a reusable template any captain can apply with whichever players are actually available that day.

Explanation

The GoF catalog organizes 23 classic patterns into three categories based on the purpose they serve. Creational patterns deal with object creation mechanisms, trying to create objects in a manner suitable to the situation while hiding the creation logic. Examples include Singleton, Factory Method, Abstract Factory, Builder, and Prototype. Structural patterns deal with how classes and objects are composed to form larger structures while keeping these structures flexible and efficient. Examples include Adapter, Decorator, Facade, Proxy, Composite, and Bridge. Behavioral patterns are concerned with algorithms and the assignment of responsibilities between objects, focusing on communication between them. Examples include Observer, Strategy, Command, State, Template Method, and Iterator.

🏏

Cricket analogy: Creational patterns are like scouting and recruiting a new player without the captain worrying how the contract was negotiated; structural patterns are like organizing the batting order; behavioral patterns are like the calling system between running batters.

Using design patterns gives engineers a shared vocabulary. Instead of describing a long implementation, a developer can simply say 'we used a Factory here' and other engineers immediately understand the intent, trade-offs, and typical structure involved. Patterns also encode decades of accumulated experience about what tends to work well and what tends to create maintenance problems.

🏏

Cricket analogy: When a commentator says 'that's a textbook cover drive,' every viewer instantly understands the footwork and shot shape involved without a lengthy explanation, the same shared vocabulary a 'Factory' name gives engineers.

Example

python

# A tiny taste of each category, illustrated conceptually

# Creational: Factory Method decides which class to instantiate
class Dog:
    def speak(self):
        return "Woof"

class Cat:
    def speak(self):
        return "Meow"

def animal_factory(kind):
    return {"dog": Dog, "cat": Cat}[kind]()

# Structural: Adapter converts one interface into another
class OldPrinter:
    def print_old(self, text):
        return f"[old] {text}"

class PrinterAdapter:
    def __init__(self, old_printer):
        self._old_printer = old_printer
    def print(self, text):
        return self._old_printer.print_old(text)

# Behavioral: Observer notifies subscribers of state changes
class Publisher:
    def __init__(self):
        self._subscribers = []
    def subscribe(self, fn):
        self._subscribers.append(fn)
    def publish(self, event):
        for fn in self._subscribers:
            fn(event)

if __name__ == "__main__":
    pet = animal_factory("dog")
    print(pet.speak())
    adapter = PrinterAdapter(OldPrinter())
    print(adapter.print("hello"))
    pub = Publisher()
    pub.subscribe(lambda e: print(f"received: {e}"))
    pub.publish("new order")

Analysis

Notice how each snippet solves a distinct kind of problem: the factory hides which concrete class gets instantiated, the adapter reconciles two incompatible interfaces, and the observer decouples a publisher from the subscribers that react to its events. This is the essence of pattern categorization — Creational patterns answer 'how do I get an object?', Structural patterns answer 'how do objects fit together?', and Behavioral patterns answer 'how do objects communicate and share responsibility?'. Misclassifying a pattern (for example, calling Decorator a Behavioral pattern) signals a misunderstanding of its actual intent, since Decorator is fundamentally about object composition, not communication.

🏏

Cricket analogy: The team's scout answers 'who joins the squad?', the batting order answers 'how do players line up?', and the calling system between running batters answers 'how do partners coordinate?' — three distinct concerns.

Patterns should be applied judiciously. Overusing them on simple problems adds indirection and complexity without benefit — a phenomenon sometimes called 'pattern overkill.' The best engineers reach for a pattern only when the problem it solves is actually present in their code, and they can name the specific pain point (rigid object creation, incompatible interfaces, tangled notification logic) that the pattern addresses.

🏏

Cricket analogy: Rotating four specialist fielding coaches for a routine club match, when a single all-purpose coach handles it fine, adds overhead nobody needed — the pattern should only appear when a real, named problem like a genuinely tricky pitch demands it.

Key Takeaways

The Gang of Four catalog defines 23 patterns split into Creational, Structural, and Behavioral categories.
Creational patterns (Singleton, Factory Method, Abstract Factory, Builder, Prototype) manage object creation.
Structural patterns (Adapter, Decorator, Facade, Proxy, Composite, Bridge) manage how objects and classes are composed.
Behavioral patterns (Observer, Strategy, Command, State, Template Method) manage communication and responsibility between objects.
Patterns provide a shared vocabulary but should only be applied when they solve a real, present problem.