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.

Naming boundary. Java's Cipher.getInstance() is a useful static factory method, but that API is not by itself the GoF Factory Method pattern. The GoF pattern defines a creation operation that subclasses override:

abstract class ReportExporter {
  public final Report export(ReportData data) {
    ReportWriter writer = createWriter();
    return writer.write(data);
  }
  protected abstract ReportWriter createWriter();
}

final class PdfExporter extends ReportExporter {
  @Override
  protected ReportWriter createWriter() {
    return new PdfReportWriter();
  }
}

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,” and do not confuse the GoF pattern with every method that returns an object.

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.