Choosing Design Patterns

A design pattern describes a recurring problem and a useful arrangement of responsibilities. It is a vocabulary for reasoning, not a requirement to make every program look the same. Begin with what is changing, what must stay correct and where the failure boundary lies.

This group covers the 23 classic object-oriented patterns, four application patterns and 15 service/system patterns. These are a broad established catalog, not a measured popularity ranking. Some, such as Interpreter or Visitor, fit specialized problems; you can return to them when that problem appears.

An object groups related values and operations. A method is an operation provided by that object. A class describes a way to create related objects; a constructor sets up a new instance. A supplied function can also represent a small interchangeable behaviour.

The JavaScript examples use console.log to show results. An arrow function is a concise way to write a function; true and false are boolean values. A Map holds values under keys. Focus first on who calls whom and who owns the state, then inspect the syntax in the small example.

The code output is shown directly below each example. These examples can be run in a current JavaScript environment, but local success does not verify a real network, database or concurrency contract. The lesson explains that boundary separately.

These patterns address construction choices and ownership. Learn Factory Method, Abstract Factory and Builder when creation genuinely varies; read Prototype for copying and Singleton with careful scope and lifetime boundaries.

• Factory Method: Owns exportReport.
• Abstract Factory: Creates related products.
• Builder: Collects construction state.
• Prototype: Applies a copying policy.
• Singleton: Gets the registry.

These patterns arrange objects and interfaces. Compare Adapter and Bridge before choosing a wrapper; they solve different extension problems. Facade simplifies a subsystem, while Composite models a nested structure.

• Adapter: Translates the interface and units.
• Bridge: send(message).
• Composite: Delegates to children.
• Decorator: Adds a label.
• Facade: Coordinates a useful operation.
• Flyweight: Owns its character and position.
• Proxy: Loads or checks access.

These patterns describe how work is chosen, delegated, announced or revisited. Strategy, Observer, State and Command are useful starting comparisons. Iterator, Template Method and Chain of Responsibility make traversal and sequences explicit. The more specialized patterns remain available when their problem fits.

• Strategy: Uses the shared price contract.
• Observer: Announces a local change.
• Command: Carries action and parameters.
• Template Method: Parses a supported format.
• Iterator: Keeps traversal progress.
• State: Arrives under an event identity.
• Chain of Responsibility: May reject malformed input.
• Mediator: Applies interaction rules.
• Memento: Captures a prior state.
• Visitor: Selects the element-type operation.
• Interpreter: Supplies allowed flag values.

These patterns are commonly taught alongside the classic catalog. They connect construction, domain access, transaction boundaries and presentation. They are distinct from the 23-pattern classic list.

• Dependency Injection: Declares the capability it needs.
• Repository: Names domain-oriented access.
• Unit of Work: Tracks or stages those changes.
• Model–View–Controller: Coordinates input and response.

Moving work between services adds network, data and lifecycle responsibilities. These lessons explain the mechanisms behind frequently used approaches rather than treating product names as guarantees. Existing sections in the component and architecture lessons remain in place.

• Cache-Aside: Requires an authoritative read.
• Write-Through and Write-Behind: Immediate source write or buffered work.
• Publisher/Subscriber: Routes under a messaging contract.
• Transactional Outbox: Contains stable event identity.
• CQRS: Keeps the business invariant.
• Event Sourcing: Retains accepted ordered facts.
• Saga: Reserves identified stock.
• Circuit Breaker: Opens under a configured failure rule.
• Bulkhead: Has its own slot budget.
• Retry with Backoff and Jitter: Decides if another attempt is appropriate.
• Sidecar: Provides a supporting capability.
• Backends for Frontends: Shapes and coordinates its interface.
• Gateway Aggregation: Coordinates under a shared deadline.
• Anti-Corruption Layer: Maps meaning and rejects unsupported cases.
• Asynchronous Request/Reply: Performs durable pending work.

Two similar-sounding problems need different boundaries. Decide which responsibility the design must actually control.

Start with Factory Method for a creation extension, Adapter for an existing mismatch, Strategy for a variable algorithm, or Outbox for a durable publication gap.

The classic catalog is described by the publisher’s Design Patterns book listing; service patterns are documented in Microsoft’s architecture catalog. This course uses original examples. Continue with small experiments and further reading to test the mechanism rather than only drawing it.