Design Patterns Module Conclusion

In this module, you learned to treat patterns as named, reusable collaborations that solve recurring design problems. Patterns improve communication (“use Strategy here”), help localize change, and create testable seams in code. You also saw how pattern scope (Class vs. Object) changes when variability is resolved-compile-time via inheritance versus runtime via composition.

What we established

• The four essentials: Name, Problem, Solution, Consequences let you reason, compare trade-offs, and document design intent succinctly.
• Categories by intent: Creational (how to create), Structural (how to compose), Behavioral (how to collaborate).
• Scope: Class patterns fix variation by overriding; Object patterns favor composition and are more flexible at runtime.
• Naming precision: Prefer exact names-Factory Method vs. Abstract Factory-and avoid vague labels like “Factory Pattern.”

Key takeaways for practice

• Write the problem first. Capture forces and constraints; the pattern choice should fall out of what must vary.
• Prefer composition. Inject behavior behind interfaces; keep concrete classes out of public APIs.
• Document consequences. Record performance, complexity, and testing impacts for future readers.
• Keep it minimal. Patterns add indirection-apply them where variability exists, not by default.

From lessons to the project

In the traffic-signals project, you modeled car and pedestrian controllers as state machines and coordinated them safely. That exercise mirrors real-world pattern use: identify variability (timing, phases), isolate it (state/strategy), and connect parts through a narrow API (coordinator/mediator).

What’s next: Singleton (preview)

Next module, you’ll constrain system-wide coordination to one instance. The Singleton pattern enforces a single access point-useful for central schedulers, configuration registries, or device gateways when global uniqueness is a requirement.

// Java - simple, lazy, thread-safe Singleton (Initialization-on-demand holder)
public final class IntersectionController {
  private IntersectionController() { /* wire timers, sensors, policies */ }
  private static final class Holder {
    static final IntersectionController INSTANCE = new IntersectionController();
  }
  public static IntersectionController getInstance() { return Holder.INSTANCE; }

  // Example API
  public void requestCrossing() { /* ... */ }
  public void setTimingProfile(TimingProfile p) { /* ... */ }
}

Self-check

• Given a feature that must switch algorithms at runtime, which scope and pattern fit best? Why?
• For a fixed algorithm skeleton with overridable steps, which scope/pattern is appropriate?
• List two consequences of choosing composition over inheritance in your current codebase.

Proceed to the next module to learn how to implement Singleton correctly and integrate it with your traffic-signals coordinator.