Creational Patterns

Carry a map from each already-copied original object to its copy. Before copying anything, look it up: if it is in the map, reuse that copy instead of recursing. This stops infinite loops on cycles and keeps shared objects shared in the copy.

Anything that identifies the object or ties it to the outside world: database IDs, creation timestamps, version counters, open connections and file handles, locks, caches and registered listeners. These should be reset, regenerated, or re-established rather than duplicated.

One per isolated runtime unit — normally one process (and, in some runtimes, one class loader or module instance). Run two processes, replicas, or workers and you have several. Reflection, deserialization, cloning, and code reloading can also create extras inside one process.

Add creational indirection only where something genuinely varies — a second implementation, a lifetime rule, or complex assembly. If a factory has one implementation, its methods just forward to one constructor, and nothing is chosen at runtime, delete it and call the constructor.

Class creational means the variation comes from inheritance — a subclass overrides a creation method, so the choice is fixed when you pick the subclass. Object creational means creation is delegated to another object, so you can change it at runtime by swapping that object.

Because one factory object produces every part, code that uses that factory gets parts from a single variant. The guarantee is only as strong as the discipline of always going through the factory — direct construction, caching, serialization, or two factories in scope can still mix variants.

Skip Builder when a class has few, mostly required fields, or when the language already has named arguments with defaults. Builders duplicate the field list, hide missing values until runtime, and a reused builder can leak state from one product into the next.

Subclass-based creation can't pick an implementation from a config string, so systems move to a registry: a map from key to creator, filled at startup by wiring or plugin discovery. Extension becomes registration, and errors move from compile time to runtime.

Besides the maximum, a pool decides which idle object to hand out (most recently returned, or least recently), how many to keep warm and pre-create at startup, how long an object may live before being retired, and whether to health-check it before lending it out.

Serialize-then-deserialize gives a deep copy in one line and handles nested structures generically. But it is slow, copies everything including things you should not copy, silently drops fields the format cannot represent, and can lose shared references or fail on cycles.

Don't rewrite everything. Give each singleton an interface and instance methods, keep the static accessor as a thin wrapper that delegates to one injected instance, then move call sites to constructor injection module by module, starting with the ones causing test pain. Delete the accessor last.