Why Design Patterns Matter for Programmers

Design Patterns

Chapter 1 · Why Design Patterns Matter for Programmers

A design pattern is a named, reusable solution shape for a recurring design problem — not a snippet of code to copy and paste. Pseudocode & Algorithmic Problem-Solving taught how to decompose a problem and choose an algorithmic strategy for one piece of logic; this course teaches a vocabulary for the recurring shapes those pieces tend to take once a codebase grows beyond a single function.

A Little History

In 1994, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides — collectively nicknamed the "Gang of Four" — published Design Patterns: Elements of Reusable Object-Oriented Software, cataloguing 23 patterns across three categories. Decades later, their names are still the common vocabulary programmers use to describe a design at a glance — "just make it a Factory" communicates far more, far faster, than describing the same structure from scratch every time.

Demonstration 1: The Same Behavior, Two Genuinely Different Shapes

A discount calculator, written the ordinary way — a direct if/elif chain:

def calculate_price(price, discount_type):
    if discount_type == 'percentage':
        return price * 0.9
    elif discount_type == 'flat':
        return price - 5
    else:
        return price
    

The exact same behavior, expressed as interchangeable objects instead:

class PercentageDiscount:
    def apply(self, price): return price * 0.9
class FlatDiscount:
    def apply(self, price): return price - 5
class NoDiscount:
    def apply(self, price): return price

def calculate_price_v2(price, strategy):
    return strategy.apply(price)
    

Verified directly — identical output from two structurally different implementations

Run on a price of 100: calculate_price(100,'percentage')=90.0 matches calculate_price_v2(100, PercentageDiscount())=90.0. calculate_price(100,'flat')=95 matches calculate_price_v2(100, FlatDiscount())=95. The no-discount case matches too: 100 both ways. Same inputs, same outputs, genuinely different code shapes — this is exactly what "a pattern is a shape, not a snippet" means concretely.

Demonstration 2: Why the Shape Itself Matters, Not Just Style

Suppose a new discount type is needed — a loyalty discount. In the if/elif version, calculate_price itself has to be edited, adding a new branch. In the object-based version:

class LoyaltyDiscount:
    def apply(self, price): return price * 0.85

calculate_price_v2(100, LoyaltyDiscount())
    

Verified directly — a new case, zero changes to existing code

Calling calculate_price_v2(100, LoyaltyDiscount()) returns 85.0 correctly — and calculate_price_v2 itself was never touched to make this work. Only a new, self-contained class was added. This is the actual payoff a pattern buys: not a stylistic preference, but a genuine, verifiable difference in how much existing, already-tested code has to change when a new case shows up.

(This particular shape — swapping in an interchangeable object to change behavior at runtime — is a real pattern, Strategy, covered fully in Chapter 7. This chapter deliberately doesn't name or formalize it yet — the point here is just that the shape itself is a real, reusable idea, worth naming later once its full structure has been built up properly.)

The Three GoF Categories

Category	What it addresses
Creational	How objects get created — controlling, hiding, or simplifying construction (Chapters 2-3)
Structural	How objects and classes are composed into larger structures (Chapters 4-6)
Behavioral	How objects communicate and distribute responsibility for a behavior (Chapters 7-9)

What This Course Won't Cover

The GoF catalogue has 23 patterns. This course covers 12 — the ones a working programmer runs into most often — honestly, rather than claiming exhaustive coverage:

Covered (Chapters 2-9)	Deliberately out of scope
Singleton, Factory Method, Abstract Factory, Builder, Adapter, Facade, Decorator, Composite, Proxy, Flyweight, Strategy, Template Method, Observer, State, Command, Iterator	Chain of Responsibility, Mediator, Memento, Visitor, Interpreter, Bridge, Prototype, and the remaining classic GoF patterns

The Honest Warning, Up Front

A pattern solves a real recurring problem — or it's just extra indirection

Demonstration 2 verified a genuine, measurable benefit: adding LoyaltyDiscount touched zero existing code. That benefit exists specifically because new discount types are a recurring, expected kind of change for this problem. Applying the same object-based shape to code that will realistically never need a second variation doesn't buy that benefit — it just adds a class, an interface, and a layer of indirection for nothing. This course revisits this warning fully in the capstone, with a real, worked example of a pattern applied where it genuinely doesn't belong.

Where This Connects

This chapter's finding	What it sets up
"A pattern is a shape, not a snippet," verified directly	Every later chapter shows the same pattern implemented slightly differently across examples — the shape, not the exact code, is what's being taught
The verified zero-change extensibility benefit	A concrete preview of Chapter 7's own Strategy pattern, and of the Open/Closed Principle Clean Code, SOLID & Refactoring (`cleancode1`) covers formally
The honest over-engineering warning	Directly revisited in Chapter 10's capstone with a real worked example

Hands-On Exercises

Exercise 1

Using this chapter's own two calculate_price versions as a template, add a third discount type to both versions — a "buy one get one half off" style discount that multiplies the price by 0.75 — and verify both versions agree on the result for a price of 100.

📄 View solution

Exercise 2

Using this chapter's own verified findings, explain in your own words why "a design pattern is a reusable solution shape, not literal reusable code" is a more accurate description than "a design pattern is a piece of code you can copy into different projects."

📄 View solution

Exercise 3

A developer says "the object-based version is strictly better, so I should always write code this way, even for a boolean flag that will only ever have two possible values and will never change." Using this chapter's own honest warning, explain what's wrong with treating this as a universal rule.

📄 View solution

Chapter 1 Quick Reference

A design pattern is a reusable solution shape for a recurring design problem, not literal code to copy-paste
The 1994 Gang-of-Four book catalogued 23 patterns across three categories: Creational, Structural, Behavioral
Verified directly: an if/elif discount calculator and an object-based version produced identical results (90.0, 95, 100) — two genuinely different shapes, same behavior
Verified directly: adding a new discount type touched zero existing code in the object-based version — the real, measurable payoff a pattern can buy
This course covers 12 of the 23 classic patterns, named explicitly, rather than claiming full coverage
A pattern only pays off when its target problem is genuinely recurring — applying one where it isn't just adds indirection, a warning revisited fully in Chapter 10
Next chapter: Creational Patterns I — Singleton and Factory Method