A reusable organization of responsibilities and interactions for a recurring software-design problem. The Memento pattern separates snapshot creation/restoration from history management, while the Decorator pattern composes independent responsibilities behind one interface. A pattern specifies an arrangement rather than one mandatory class naming scheme.
A software design pattern concerned with allocating behavior and communication responsibilities among objects. Observer patterns notify dependents, while a command pattern represents a request as an object.
Separate operations from a relatively stable hierarchy of element classes. An element's accept operation calls the visitor overload appropriate to its own concrete type, combining virtual dispatch with static overload selection to obtain double dispatch. New operations can be added as visitors; adding an element type generally requires extending the visitor interface and existing visitors.
Delegate state-dependent behavior to a separate state object. Transitions replace that object, changing how subsequent requests are handled without spreading state tests through every operation.
Interchange algorithms through a common interface, allowing a client or context to select the policy without embedding every alternative in one implementation. Different strategies solve the same kind of task; the selected algorithm can be varied independently of its caller.
A software design pattern organizing composition of classes and objects into larger structures. The decorator pattern wraps a component behind the same object interface, delegating existing work and adding one responsibility. Wrappers can be nested without declaring a new class for each combination.
A software design pattern organizing how software objects are created. A prototype pattern creates an object by asking an existing example to copy itself, letting a client choose a concrete configuration at runtime through an object interface.
Provide an interface for creating a family of related products while hiding their concrete software classes. Unlike a single factory method pattern operation returning one product abstraction, an abstract factory typically exposes several related product-creation operations whose implementations coordinate a consistent family.
Declare a creation operation returning an abstract product interface and let concrete creators specialize how products are built. Clients call the creator interface rather than hard-coding construction of each concrete product. For example two regional manufacturers can implement build(carType): Car to select a concrete car and apply regional settings; optional wrappers can then be composed independently using the decorator pattern.
Provide a shared unique instance of a service or state holder. A Scala object supplies one instance of that object definition; a top-level object can therefore centralize shared state such as a registry of current scores. A singleton does not by itself implement thread safety, remove stale entries, or define the lifetime of registered objects. Those remain separate design responsibilities.
Expose a cloning operation through a common object interface and create new objects by asking a configured prototype for a copy. Concrete prototypes implement the copy operation; the client need not name their concrete software classes. This is useful when creation depends on runtime configuration or expensive reusable initial state. The contract must specify whether nested mutable data requires a deep copy; copying only outer fields can preserve unintended reference aliasing.
Represent a request and the information needed to execute it as a software object with a common command interface. Undoable commands additionally retain enough information to invert their change: an insertion retains its position and value, a deletion retains the removed value, and a positional move retains the source and final destination indices.
For sequential undo/redo, a history manager stores applied commands on one stack and undone commands on another. Undo transfers the most recent applied command to the redo stack; redo transfers its head back after reapplying it. A fresh edit clears the redo branch. Command inverses are valid under this chronological protocol, not generally after unrelated intervening edits. Saving complete immutable versions instead gives a Memento pattern implementation of the same undo/redo interface.
An undoable command records enough information to restore its input state when applied immediately after its corresponding edit. In a sequence, insertion at index is reversed by deletion at ; deletion is reversed by reinsertion of the saved value. If a move places an entry at final index after removing it from index , the inverse moves it from back to . Removing the moved entry recovers the original sequence with exactly that entry missing, which proves the inverse for both directions and for .
These local inverse identities extend to a history by applying inverses in reverse chronological order. A stack of completed commands and a stack of undone commands maintain that order. A fresh command invalidates the old redo branch. Arbitrary inverses after unrelated intervening edits need not satisfy the restoration identity. State snapshots in the Memento pattern supply a different way to realize the same chronological undo/redo contract.
Register consumers through an observation interface so that a producer can notify interested consumers without depending on all of their concrete classes. Registration can change independently of the producer's core state changes. Notifications should expose coherent states, and unregistration or update discipline is still needed to avoid stale subscriptions or notification cycles.
Expose sequential consumption through availability and next-element operations while hiding storage and traversal details. The abstraction supports common clients for arrays, linked structures or generated sequences. A separate iterator can own separate cursor state; an alias of the same iterator does not create an independent traversal.
An adapter presents an object interface expected by clients while delegating to a component with a different object interface. Correct adaptation preserves the meaning and order of operations, not merely object method names. Adapting a combined update-and-result operation to separate update and query operations requires storing the last result and specifying its initial value. An adapter should not perform a hidden dummy update just to manufacture that initial observation.

Articles by others on the same topic (1)