In the early 2000s, a phenomenon emerged in software development that experienced engineers still recall with a shudder: pattern-itis. After the Gang of Four book gained widespread popularity, eager developers began seeing patterns everywhere—and applying them everywhere. Codebases bloated with unnecessary abstractions. Simple problems drowned in architectural complexity. The cure became worse than the disease.

One legendary code review found a straightforward CRUD application with 17 design patterns applied. There was a Factory for the Factories, a Strategy for selecting Strategies, and an Observer observing the Observers. The original developer proudly explained each pattern's "purpose." The reviewer's assessment was blunt: "This is a 500-line script hidden inside 10,000 lines of pattern infrastructure."

This cautionary tale illustrates a crucial truth: knowing what patterns ARE is only half the education. You must also understand what patterns are NOT. Without this understanding, pattern knowledge becomes a liability rather than an asset.

Perhaps the most common misconception is treating patterns like recipes—find a pattern, copy its sample code, paste into your project, done. This fundamentally misunderstands the nature of patterns.

Patterns are templates for solutions, not solutions themselves.

Consider the difference:

Why copy-paste fails:

Sample code in pattern books is illustrative, not production-ready. It demonstrates the structure with minimal complexity. Real implementations must handle:

• Your domain's specific requirements: The sample Observer doesn't know about your event types
• Error conditions: Pattern samples often omit error handling for clarity
• Threading concerns: Many samples ignore concurrency for simplicity
• Performance requirements: Academic examples optimize for understanding, not performance
• Framework integration: Sample code exists in isolation; your code must integrate with existing systems

The right approach:

Understand the pattern's intent, structure, and participants. Then design your own implementation that fits your specific context. The pattern guides your thinking; it doesn't write your code.

Two valid implementations of the same pattern might share zero lines of code while sharing the same essential structure. That's the nature of patterns as templates, not code.

"We should use more patterns in this codebase." This statement reveals a dangerous mindset. Patterns are tools, not objectives. You don't earn points for patterns used.

The goal is good software, not patterned software.

Patterns are means to ends, and those ends are:

Patterns help achieve these goals in specific situations. But they're not the only way to achieve them, and they're not always the best way.

The checklist trap:

Some teams or individuals evaluate code by counting patterns. "Does it use Dependency Injection? Does it have a Factory? Is there proper separation of concerns with Strategy?" This checklist mentality leads to:

• Patterns applied where simpler solutions work fine
• Code that's harder to understand due to unnecessary abstraction
• Development time wasted on pattern infrastructure
• The illusion of quality without actual quality

The right question isn't "What patterns should we use?"

It's "What problem do we have, and what's the best solution—which might or might not be a pattern?"

Every pattern has a context—conditions under which it applies. Outside that context, the pattern creates problems rather than solving them.

The cost of patterns:

Patterns aren't free. They introduce:

When are patterns worth the cost?

Patterns pay for themselves when the problem they solve is actually present and the solution provides real benefit:

• Use Strategy when algorithms actually need to vary independently
• Use Observer when you genuinely need decoupled one-to-many notification
• Use Factory when object creation is actually complex or needs to be flexible
• Use Decorator when you truly need to add behavior dynamically

When are patterns overkill?

• The code will never need the flexibility the pattern provides
• The system is simple enough that directness is clearer
• The team lacks the experience to understand the pattern
• Performance is critical and pattern overhead matters
• You're building a prototype or throwaway code

The simplicity test:

Before applying a pattern, ask: "Can I solve this problem more simply?" If a problem can be solved with a simple function, a conditional, or direct code, do that. Patterns should be reached for when simpler approaches fall short—not as a first resort.

Pattern descriptions show archetypal structures—typically with classes named after their roles (Subject, Observer, ConcreteSubject). This leads some to believe there's a "correct" implementation that must be followed rigidly.

Patterns are adaptable, not rigid.

Consider the Observer pattern's canonical structure:

Subject
├── attach(Observer)
├── detach(Observer)
└── notify()

Observer  (interface)
└── update()

ConcreteSubject extends Subject
ConcreteObserver implements Observer

Valid adaptations:

All of these are "Observer pattern"—they share the essential structure (one-to-many notification without tight coupling) while differing in implementation details. None is more "correct" than others; each fits different contexts.

Adapt to your ecosystem:

Languages and frameworks provide facilities that patterns can leverage:

• In JavaScript, observer callbacks are often plain functions, not objects
• In C#, events and delegates provide language-level observer infrastructure
• In Rust, traits and closures shape how patterns manifest
• In functional languages, higher-order functions replace many object patterns

The pattern's essence, not its sample code, is what matters. Implement it in a way that's idiomatic to your language, framework, and team conventions.

Perhaps the most pernicious misconception is treating patterns as a mechanical substitute for design thinking. "I have a problem; I'll find the matching pattern; done." This cargo-cult approach produces poor results.

Patterns require judgment:

• Problem recognition: You must understand your problem deeply before matching it to a pattern
• Pattern selection: Multiple patterns might address the problem; you must choose wisely
• Adaptation: The pattern must be adapted to your specific context
• Trade-off evaluation: Patterns have costs; you must decide if benefits outweigh costs
• Integration: Patterns must integrate with your existing codebase coherently

None of these steps can be mechanized. They require engineering judgment—exactly the kind of thinking patterns are meant to support, not replace.

The pattern-matching trap:

Some developers maintain mental lookup tables:

• Need flexibility in algorithms? → Strategy
• Need to notify multiple objects? → Observer
• Need to create objects? → Factory

This surface-level pattern-matching ignores crucial nuances:

• Does the algorithm actually need to vary independently, or is inheritance simpler?
• Is the notification truly one-to-many, or would direct calls be clearer?
• Is object creation complex enough to warrant a factory, or is new sufficient?

Patterns guide, they don't decide.

A pattern is like a doctor's diagnosis: it provides a framework for action, but doesn't eliminate the need for professional judgment. Knowing the pattern is the beginning of the design process, not the end.

Some developers assume everyone knows patterns. They use pattern names freely, assume understanding, and write code that's opaque to those unfamiliar with the patterns. This creates accessibility problems.

Reality check:

• Many developers learned programming through bootcamps that don't cover patterns
• Self-taught developers may have focused on specific frameworks, not design theory
• Developers from non-OOP backgrounds (functional, scripting) may have different terminology
• Even experienced developers may not know all 23+ GoF patterns, let alone domain-specific ones
• Patterns known in Java/C# communities may differ from those in JavaScript/Python communities

Inclusive practices:

Team calibration:

The level of pattern sophistication in your code should match your team's capabilities. A team of senior engineers fluent in patterns can use dense pattern-based designs productively. A mixed team might need more explicit documentation and simpler structures.

Patterns should aid collaboration, not hinder it. If your pattern-based code is only readable by you, the pattern is an anti-pattern.

A pattern applied today may not be appropriate tomorrow. Requirements change, understanding deepens, and better solutions emerge. Treating patterns as permanent architecture leads to rigidity.

Patterns should be refactorable:

Just as you might refactor a function when its complexity grows, you should be able to:

• Add a pattern: When simple code becomes complex, introduce a pattern to manage it
• Remove a pattern: When pattern overhead exceeds benefit, simplify back to direct code
• Change patterns: When requirements shift, switch from one pattern to another
• Combine patterns: When systems grow, compose multiple patterns together

Signs a pattern should be reconsidered:

The evolution of design:

Good designs evolve. A system might start without patterns, acquire them as complexity grows, then simplify as the domain becomes better understood. This evolution is healthy.

Patterns are tools for a stage of development, not monuments to preserve forever. They should be as easy to refactor away as any other code—which means keeping them as simple as possible and avoiding over-engineering their implementation.

Understanding what patterns are NOT is as important as understanding what they are. Let's consolidate the boundaries we've established:

The wise pattern practitioner:

• Uses patterns judiciously, when problems genuinely call for them
• Adapts patterns to context rather than forcing context to patterns
• Explains patterns to team members and documents pattern usage
• Treats patterns as tools in a toolkit, not goals to achieve
• Remains open to simpler solutions when patterns are overkill
• Refactors to and from patterns as the system evolves

Module Complete:

You now have a comprehensive understanding of what design patterns are and are not. You know they are reusable solutions to common problems, communication tools, and design vocabulary. You also know they are not code to copy, goals in themselves, or substitutes for engineering judgment.

This foundation prepares you for the next module, where we'll explore the history and origins of design patterns—the Gang of Four book that catalyzed the pattern movement and shaped modern software design thinking.