Creational Patterns

• Decouple what gets created from the code that asks
• Callers depend on an interface, not a concrete class

• new ConcreteClass() scattered around
• Constructors with many parameters
• Switch on a type tag

• Why use a creational pattern? Callers depend on an interface, not a class
• Many optional parameters? Builder
• Which question does Abstract Factory answer? Which family?
• When to refactor to a pattern? When the variation appears

• Exactly one instance plus a global access point
• Private constructor, static field, static getInstance()

• Hidden global state
• Hard to unit test: cannot swap in a mock
• Breaks with one per tenant or per process

• Base class declares create(); subclasses choose the concrete product
• Use when the class is unknown until runtime or a framework lets users plug in products

• A subclass per product explodes the class count; use a static factory if no extension is needed

• One interface, one create method per product: createButton(), createCheckbox()
• Each concrete factory returns a matching set: DarkThemeFactory, LightThemeFactory
• Use when products belong together and are never mixed across families
• Typical cases: UI themes, cross-platform widgets, per-database DAOs

• Separate construction of a complex object from its representation
• Chained calls end in build(), which returns an immutable result
• Cures the telescoping constructor: many optional parameters

Pizza p = new Pizza.Builder()
    .size(L)
    .cheese()
    .build();  // validates, then freezes

chain the options, build() last

• build() must validate required fields, or you get half-built objects
• Overkill for objects with two or three fields: use a plain constructor

• Prototype: new object by clone() of an existing instance
• Skips costly init: DB loads, heavy config
• Shallow copy shares nested refs; mutating the clone hits the original
• Deep-copy mutable fields; beware circular refs

import copy
a = {"t": [1]}
s, d = a.copy(), copy.deepcopy(a)
a["t"].append(2)
print(s["t"], d["t"])

shallow copy s sees the change, deep copy d does not

• Factory: finished object in one call
• Builder: assembled in steps, parts vary
• Abstract Factory can use Builders or Prototypes inside

• Used as a convenient global: hides dependencies, tests become order-dependent
• Fix: inject the one shared instance
• Lazy init without a lock: two threads can both create it

private static volatile Db inst;
static Db get() {
  if (inst == null) synchronized (Db.class) {
    if (inst == null) inst = new Db();
  }
  return inst;
}

double-checked locking

• Factory or Builder on a simple object: extra indirection, no variation to justify it

• Prototype pays off when an object is costly to create but cheap to copy

• Singleton: private constructor + static getInstance()
• Thread-safe: enum or eager init; inject, don't go global
• Factory Method: subclass overrides create(), returns one product
• Abstract Factory: one interface, a product family; easy to add families, hard to add products
• Builder: stepwise, final build() validates; often immutable
• Prototype: clone() an object; pick shallow or deep first

• Lazy singleton without a lock: two instances
• Builder without validation in build(): half-built objects