Design Patterns — Definition & Example

What is a design pattern?

A design pattern is a general, reusable solution to a commonly occurring design problem within a given context in software design. It is a proven template — not finished code, but a description of how to solve a recurring problem, including the classes, responsibilities, and relationships involved.

Parts of a pattern:

1. Name — a standard vocabulary term (e.g., Singleton, Observer).
2. Problem — the context/situation where the pattern applies.
3. Solution — the elements (classes/objects), their responsibilities, and relationships.
4. Consequences — trade-offs, benefits, and drawbacks of applying the pattern.

Categories (GoF — Gang of Four): Creational (object creation), Structural (composition of classes/objects), Behavioral (interaction/responsibility between objects).

Example: The Observer pattern (behavioral)

Problem: One object (subject) changes, and many dependent objects need to be notified/updated automatically — without the subject knowing the specifics of the dependents (loose coupling). Example: a stock-ticker application where a price change must refresh several displays/charts.

Solution:

• Subject maintains a list of observers and provides attach(), detach(), notify().
• Observer interface defines update().
• Concrete observers register with the subject; when the subject's state changes it calls notify(), which invokes update() on every registered observer.

            ┌──────────────┐  attach/notify   ┌────────────────┐
            │   Subject    │◀─────────────────│    Observer    │
            │──────────────│                  │  update()      │
            │ attach(obs)  │                  └────────────────┘
            │ detach(obs)  │                        ▲
            │ notify()     │                        │ implements
            └──────┬───────┘                        │
                   │ state change                  ┌─┴────────────┐
                   └────── notify all ────────────▶│ ConcreteObs  │
                                                  └──────────────┘

Use/benefit: the displays and the data model are decoupled; adding a new display requires no change to the subject (open–closed principle). Used in event systems, MVC (model notifies views), and pub-sub messaging.

Why patterns are useful

• Capture proven design experience (not invented from scratch).
• Provide a shared design vocabulary among developers.
• Make designs more maintainable, extensible, and easier to communicate/review.

Other examples: Singleton (one instance), Factory Method (object creation delegated), Adapter (interface conversion), Strategy (interchangeable algorithms).