zenobi-us Software Design Patterns
Read the reference file that matches the design constraint you face. Each file gives intent, applicability signals, contraindications, an implementation checklist, and misuse checks for one pattern.
Creational Patterns
Use these when object creation itself is the problem.
- Abstract Factory — Use when you must create compatible sets of related objects without binding client code to concrete classes.
- Builder — Use when object construction requires many ordered or optional steps and constructor signatures are becoming brittle.
- Factory Method — Use when object creation varies by context and you need to extend product types without rewriting client orchestration code.
- Prototype — Use when object creation is expensive or dynamic and cloning existing configured instances is safer than rebuilding from scratch.
- Singleton — Use when exactly one coordinated instance is required and its lifecycle, access, and state boundaries can be strictly controlled.
Structural Patterns
Use these when the problem is how objects and classes fit together.
- Adapter — Use when an existing class has useful behavior but an incompatible interface blocks integration with client code.
- Bridge — Use when abstractions and implementations need to evolve independently without creating subclass explosion.
- Composite — Use when clients must treat individual objects and nested object groups uniformly through one interface.
- Decorator — Use when responsibilities must be added dynamically to objects without subclass proliferation.
- Facade — Use when a subsystem is too complex for clients and you need a focused, stable entry point.
- Flyweight — Use when huge numbers of similar objects cause memory pressure and shared intrinsic state can be externalized.
- Proxy — Use when access to an object must be controlled, deferred, secured, or monitored through a surrogate.
Behavioral Patterns
Use these when the problem is how objects communicate or change behavior.
- Chain of Responsibility — Use when multiple handlers may process a request and you need flexible routing without hard-coding sender-to-receiver coupling.
- Command — Use when operations must be represented as objects so execution, scheduling, undo, and logging can vary independently from invokers.
- Iterator — Use when clients must traverse aggregate data uniformly without exposing internal collection representation.
- Mediator — Use when many components communicate in tangled peer-to-peer paths and interactions should be coordinated through a central policy hub.
- Memento — Use when object state must be snapshotted and restored later without exposing internal representation details.
- Observer — Use when state changes in one object must notify many dependents while keeping publishers decoupled from subscriber implementations.
- State — Use when an object's behavior changes by internal mode and conditional branches are growing around state transitions.
- Strategy — Use when multiple interchangeable algorithms are needed and clients should switch behavior without branching on concrete implementations.
- Template Method — Use when an algorithm skeleton is stable but specific steps must vary across implementations without duplicating workflow structure.
- Visitor — Use when stable object structures need new operations added frequently without modifying each element class.