10 — Pattern Theory & Pattern Languages

Driving question: What makes a reusable design idea a pattern rather than an idiom or recipe?

Learning objectives

• Explain context, problem, forces, solution, and consequences.
• Distinguish pattern intent from implementation shape.
• Understand pattern languages and relationships among patterns.
• Recognize pattern drift and naming ambiguity.

Pattern form

A useful pattern description captures:

• Context — where the problem appears;
• Problem — recurring design tension;
• Forces — competing considerations;
• Solution — recurring arrangement of responsibilities/collaborations;
• Consequences — benefits, liabilities, and new problems.

Pattern names create a shared design vocabulary, but naming introduces a research challenge: code may implement the same intent with different structures, and similar structures can embody different intent.

Pattern language

Patterns rarely appear alone. A pattern language relates patterns through sequences, alternatives, refinements, and consequences. This idea becomes important when automating recommendation: the “next pattern” depends on the design state and forces, not only local syntax.

Design / research exercise

Take a commonly named “pattern” from a framework ecosystem. Decide whether it is a design pattern, architectural pattern, idiom, convention, or API-specific recipe. Defend the classification.

Suggested reading

• Gamma et al., Design Patterns.
• Christopher Alexander, pattern-language ideas (conceptual background).