Design Pattern Components

Standard Names for Design Patterns

Names aren’t perfectly fixed-e.g., Abstract Factory has appeared as “Kit”-but de facto conventions let teams communicate precisely. Saying “use Factory Method here” is far more compact than re-explaining creation decoupling each time.

Example. In Java’s crypto API, the call below selects and returns a configured cipher without the caller knowing the concrete class-this is idiomatic Factory Method:

Cipher c = Cipher.getInstance("AES/GCM/NoPadding"); // Factory Method creates the right implementation

Naming precision. Prefer the specific GoF names: Factory Method (single-object creation hook) and Abstract Factory (families of related objects). Avoid the vague phrase “Factory Pattern.”

Motivation

Modular systems evolve. Patterns give you names for the recurring forces (where variation lives) and structures that control that variation without hard-wiring it into inheritance trees or call sites. For example, Abstract Factory supplies entire families of related products (e.g., UI widgets for a theme), while Factory Method defers the choice of a single product to subclasses or injected creators.

What Are the Elements of a Design Pattern?

1. Name - A one- or two-word handle that lets pattern-literate developers communicate quickly (e.g., Factory Method, Singleton, Mediator, Prototype). A good name evokes both the problem and the solution idea.
2. Problem (Intent & Motivation) - When to apply the pattern and why. Example: Singleton ensures a single instance controls access to a unique resource (e.g., audio device handle).
3. Solution (Structure & Collaboration) - The participating classes/objects, their responsibilities, and collaborations. Emphasize relationships (roles, interfaces, delegation) over concrete classes, so the template applies broadly.
4. Consequences (Trade-offs) - The results of applying the pattern: complexity vs. flexibility, time/space cost, testability, scalability, and portability. Consequences help you compare alternatives.

Behavioral, Creational, Structural

Patterns are often grouped by intent: Creational (object creation variability), Structural (object composition and API shape), Behavioral (responsibility and communication). Use the category as a guide, not a rule.

Big-O and Patterns

You don’t do formal Big-O on patterns the way you do on algorithms, because patterns leave many details unspecified. Still, you can reason about typical trade-offs: e.g., Decorator may add indirection cost; Flyweight can reduce memory at the expense of coordination overhead.

Quick Checklist

• Choose precise names: Factory Method vs. Abstract Factory; Adapter vs. Facade.
• Write the problem as a test: Capture intent with an executable example.
• Sketch the structure: Roles, interfaces, collaborations-keep concretes out of the API.
• List consequences explicitly: Performance, flexibility, testing impact, migration path.