Software Engineering Roadmap

Learn how to build, test, deploy, and maintain robust software systems.

Overall Progress0%

Design Patterns

Explanation

A design pattern is a reusable, named solution to a recurring design problem. Patterns are not copy-paste code; they are templates that describe how a problem is commonly solved, so that developers can communicate about them and apply them where they fit. This lesson introduces the three categories of patterns — creational, structural, and behavioral — plus dependency injection, and walks through the Observer pattern in detail. It also stresses the most important skill: knowing when not to use a pattern. Patterns are tools, not goals. The best design is often the simplest one that works.

What Is a Design Pattern?

Recurring design problem

↓

Known reusable approach

↓

Shared vocabulary

Why Patterns Exist

They give developers a shared vocabulary.
They reuse proven solutions.
They often reduce coupling.

When NOT to Use a Pattern

Creational Patterns

Factory: create objects through a method so callers do not need the concrete class.
Builder: construct a complex object step by step.
Singleton: ensure only one instance exists — useful for a single configuration or connection, but often overused.

Structural Patterns

Adapter: translate one interface into another.
Decorator: add behavior to an object without changing its interface.
Facade: provide a simple interface over a complex subsystem.

Behavioral Patterns

Observer: notify many subscribers when an event happens.
Strategy: make an algorithm swappable.
Command: wrap a request as an object.

Dependency Injection

Dependency injection passes a dependency into an object instead of having the object create it. This makes the object easier to test and reduces coupling.

Object depends directly on a class

↓

becomes

↓

Object receives the dependency

The Observer Pattern

Publisher

↓

Event

↓

Subscribers

A publisher holds a list of subscribers and notifies them when an event occurs. Subscribers can be added or removed without the publisher knowing their details — this is loose coupling.

Pattern Comparison

Pattern	Category	Problem	Typical use
Factory	Creational	Creating objects without coupling to a concrete class	When the exact type is chosen at runtime
Adapter	Structural	Incompatible interfaces	Wrapping a third-party library
Observer	Behavioral	Notify many objects of a change	Event systems, UI updates
Strategy	Behavioral	Swappable algorithms	Payment methods, sorting

Patterns vs Principles vs Frameworks

Principles are general guidance (SOLID).
Patterns are recurring solution structures.
Frameworks are concrete tools that may use patterns internally.

Syntax

An Observer event bus in Pythonpython

1class EventBus:2    def __init__(self):3        self._subscribers = {}4 5    def subscribe(self, event, callback):6        self._subscribers.setdefault(event, []).append(callback)7 8    def emit(self, event, data):9        for callback in self._subscribers.get(event, []):10            callback(data)11 12bus = EventBus()13bus.subscribe("notify", lambda msg: print("got:", msg))14bus.emit("notify", "hello")

The publisher (bus) does not know what its subscribers are — they are decoupled.

Examples

Strategy pattern

Make the sort key swappable without changing the caller.

python

1def sort_by(items, key):2    return sorted(items, key=key)3 4sort_by(users, key=lambda u: u.name)

Output

(the strategy is the key function)

Key Takeaways

Patterns are reusable solutions to recurring problems.
Categories: creational, structural, behavioral.
Dependency injection reduces coupling and improves testability.
Observer notifies subscribers without the publisher knowing them.
Do not force patterns onto simple problems.

← PreviousClean Code & Refactoring Next →System Architecture