Who ya gonna call?

  • The system shall be "platform-independent"
  • The system shall be independent of how its constituent pieces are created, composed, and represented.
  • The system shall be configured with one of multiple families of products.
  • A family of products designed to be used together shall have their relationship constraints enforced.
  • "case" statements are a maintenance nightmare - they shall be avoided.
  Abstract
Factory
  • The algorithm for creating a complex subsystem shall be independent of the parts that make up the subsystem and how the parts are assembled.
  • The creation process for a complex subsystem shall support multiple representations of that subsystem.
Builder
  • A subsystem shall not have the "type" of component it is responsible for creating hard-wired.
  • The system shall be "open for extension, but closed for modification".
Factory
Method
  • The overhead of component creation shall be localized and minimized. Instead of creating entirely new instances of a component type, a "prototypical" instance of each type shall be designed to "clone" itself.
  • Decisions about the type of component to create shall be deferred until application run-time.
Prototype
  • A single instance of a subsystem shall be enforced, and the subsystem itself shall be responsible for that enforcement.
  • The single instance shall be globally accessible.
  • The single instance shall be initialized only if, and when, it is accessed.
Singleton
  • A legacy component shall be reused in a new design, and the interface "impedance mismatch" shall be reconciled.
  • A reusable component shall cooperate with unrelated (or unforeseen) application components.
Adapter
  • Component interfaces shall be decoupled from their implementation(s).
  • The client shall be "insulated" from implementation changes. [Changes to implementation details should only require a re-link, not a re-compile.]
  • The choice of implementation shall be configurable at run-time.
  • Both the "interface" and the "implementation" shall be separately "open for extension, but closed for modification".
  • "Interface" components that represent "implementation" components that are "expensive" and "equal" shall share these implementations, instead of duplicating them.
Bridge
  • The system shall support recursive composition.
  • The system shall support "whole-part" hierarchical assemblies of components.
  • Clients shall be able to transparently interact with compositions of components (e.g. a sub-tree) and individual components (e.g. a node).
Composite
  • Components shall be extensible at run-time.
  • Functionality shall be "layer-able". The client shall be capable of configuring any combination of capabilities by simply specifying the layers (or wrappers, or onion skins) to be applied.
Decorator
  • The system shall provide a simple interface to a complex subsystem.
  • The system shall provide alternative novice, intermediate, and "power-user" interfaces.
  • The system shall decouple subsystems from each other.
  • The system shall support "layering" of subsystems.
Facade
  • The system shall employ hundreds of components at very fine levels of granularity without prohibitive cost.
  • The system shall support pooling and reuse of a finite supply of "x" across an inexhaustible demand.
Flyweight
  • The system shall support "distributed processing" by providing a local representative for a component in a different address space.
  • The system shall support "lazy creation" - a component is created only if, and when, the client demonstrates an interest in it.
  • The system shall control access to components by interposing an intermediary that evaluates the identity and access priviledges of the requestor.
  • The system architecture shall be characterized by multiple dimensions of indirection that offer a locus for intelligence that would unduly complicate other components if they were obliged to support the additional responsibility.
Proxy
  • The system shall allow the client to issue a request to one of several "handlers" without knowing or specifying the receiver explicitly.
  • The system shall allow a suite of "handlers" to be configured at run-time.
  • The system shall allow the client to "launch and leave" a request with a "virtual pipeline of handlers".
  • "Senders" and "receivers" shall be decoupled from one another.
Chain of
Responsibility
  • The system architecture shall provide a "callback" framework.
  • The system shall encapsulate "execute" requests so that they may be created, queued, and subsequently serviced. They may also be logged, archived, loaded, and re-applied.
  • The system shall support hierarchical compositions of primitive "command" abstractions.
  • The system shall support reuse of "command" abstractions. [Define a "command", and simultaneously attach the encapsulation to a push button, a toolbar icon, a menu item, and a keyboard accelerator - so that all users of the GUI can enjoy their preferred method of interaction.]
  • The system shall support "redo"
  • The system shall support transactions
  • "Senders" and "receivers" shall be decoupled from one another.
Command
  • The system shall characterize the domain as a set of rules, then define a language capable of specifying the rules, and a grammar for defining the language, and an "engine" for interpreting the grammar.
Interpreter
  • The system shall support accessing an aggregate component's contents without exposing its internal representation.
  • The system shall support multiple simultaneous traversals of aggregate components without complicating the implementation of the aggregate itself.
  • The system shall define a uniform interface for traversing dissimilar aggregate components.
  • The system shall decouple "data structures" from "algorithms" so that each can be developed, maintained, and used independent of the other.
Iterator
  • The system shall encapsulate complex, many-to-many coupling between "peer" components in a separate component capable of allowing the "peers" to be: disengaged, replaced, and reused.
  • The system shall support numerous many-to-many "mappings" to be defined, installed, and exchanged by the client.
  • The system shall balance the distribution of intelligence emphasized by "logical" OO design with the centralization of intelligence often required by "physical" large scale design.
  • "Senders" and "receivers" shall be decoupled from one another.
Mediator
  • The system shall support "undo" or "rollback"
  • The system shall support transactions
  • The system shall support saving, or "flattening", or "streaming" components without compromising their encapsulation.
Memento
  • The system shall support multiple "views" of the same "model" (or "subscribers" to the same "publisher", or "consumers" to the same "producer").
  • Each "model" component shall be decoupled from the number and type of its "view" components.
  • Each "view" component shall be capable of driving the flow of information from the "model" to itself.
  • "Independent" components shall be decoupled from "dependent" components.
  • "Senders" and "receivers" shall be decoupled from one another.
Observer
  • Components shall be capable of "morphing" their behavior at run-time.
  • The system architecture shall be characterized by a "finite state machine". The state machine will need to support application logic at each state transition, not simply the transition itself. [A "table-driven" approach routinely supports only the latter.]
  • "case" statements are a maintenance nightmare - they shall be avoided.
State
  • Clients shall be decoupled from "choice of algorithm".
  • Clients shall be decoupled from complex, algorithm-specific data structures.
  • The choice, or implementation, of algorithm shall be configurable at run-time.
  • "case" statements are a maintenance nightmare - they shall be avoided.
Strategy
  • Individual steps of an algorithm shall be defineable or replaceable.
  • The system shall provide "hooks" wherever future functionality or extensibility may be required.
  • The "invariant" parts of an algorithm shall be implemented in one place, and reused all other places.
  • The "standard" parts of an algorithm shall be implemented and enforced in one place.
  • Reuse shall be emphasized by architecting a "don't call us, we'll call you" framework.
  • The system shall be "open for extension, but closed for modification".
Template
Method
  • The system shall allow the operations that can be performed on "whole-part" hierarchical assemblies of components to be defined and added without having to change (and potentially break) any existing code.
  • The system shall decouple "data structures" from "algorithms" so that each can be developed, maintained, and used independent of the other.
  • The design shall support the recovery of "lost type information" without resorting to the overhead associated with RTTI.
  • "case" statements are a maintenance nightmare - they shall be avoided.
  • The system shall be "open for extension, but closed for modification".
Visitor