Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
The Abstract Factory Pattern provides a way to encapsulate a group of individual factories that have a common theme. In normal usage, the client software would create a concrete implementation of the abstract factory and then use the generic interfaces to create the concrete objects that are part of the theme. The client does not know (nor care) about which concrete objects it gets from each of these internal factories since it uses only the generic interfaces of their products. This pattern separates the details of implementation of a set of objects from its general usage.
Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.
The form of the Adapter shown below uses delegation from the adapter to the foreign class to reuse the pre-existing behavior:
The form of the Adapter (called the Class Adapter) shown below uses inheritance:
The Adapter Design Pattern 'adapts' one interface for a class into one that a client expects. An adapter allows classes to work together that normally could not because of incompatible interfaces by wrapping its own interface around that of an already existing class. The adapter is also responsible for handling any logic necessary to transform data into a form that is useful for the consumer.
Decouple an abstraction from its implementation so that the two can vary independently.
When an abstraction can have one of several possible implementations, the usual way to accommodate them is to use inheritance. An abstract class defines the interface to the abstraction, and concrete subclasses implement it in different ways. But this approach isn't always flexible enough. Inheritance binds an implementation to the abstraction permanently, which makes it difficult to modify, extend, and reuse abstractions and implementations independently.
When a class varies often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge about the program. The Bridge Pattern is useful when not only the class itself varies often but also what the class does. The class itself can be thought of as the abstraction and what the class can do as the implementation.
Separate a varying entity from a varying behavior (AKA seperate an "abstraction" from its "implementation"), so that these issues can vary independently. Sometimes we say it this way: separate what something is from what it does, where both of these things vary for different reasons.
Separate the construction of a complex object from its representation so that the same construction process can create different representations.
The Builder Design Pattern encapsulates the logic of how to put together a complex object so that the client just requests a configuration and the Builder directs the logic of building it.
The Builder pattern allows a client object to construct a complex object by specifying only its type and content. The client is shielded from the details of the object's construction.
It is a pattern for step-by-step creation of a complex object so that the same construction process can create different representations is the routine in the builder pattern that also makes for finer control over the construction process. All the different builders generally inherit from an abstract builder class that declares the general functions to be used by the director to let the builder create the product in parts.
Builder has a similar motivation to the Abstract Factory but, whereas in that pattern, the client uses the Abstract Factory class methods to create its own object, in Builder the client instructs the builder class on how to create the object and then asks it for the result. How the class is put together is up to the Builder class. It's a subtle difference.
The Builder pattern is applicable when the algorithm for creating a complex object should be independent of the parts that make up the object and how they are assembled and the construction process must allow different representations for the object that's constructed.
Use the Builder pattern when:
the algorithm for creating a complex object should be independent of the parts that make up the object and how they're assembled.
the construction process must allow different representations for the object that's constructed.
Chain of Responsibility
Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.
The Chain of Rresponsibility pattern is a design pattern consisting of a source of command objects and a series of processing objects. Each processing object contains a set of logic that describes the types of command objects that it can handle, and how to pass off those that it cannot to the next processing object in the chain. A mechanism also exists for adding new processing objects to the end of this chain.
Use Chain of Responsibility when:
more than one object may handle a request, and the handler isn't known a priori. The handler should be ascertained automatically.
you want to issue a request to one of several objects without specifying the receiver explicitly.
the set of objects that can handle a request should be specified dynamically.
Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.
Encapsulate an operational request of a Service into an entity (Command), so that the same Service can be used to trigger different operations. Optionally, this can be used to support undo, logging, queueing, and other additional behaviors. This is typically used to separate non-changing code (framework code) from changing code (plugin code) when a reusable object framework is created.
Use the Command Design Pattern when you want to:
parameterize objects by an action to perform. You can express such parameterization in a procedural language with a callback function, that is, a function that's registered somewhere to be called at a later point. Commands are an object-oriented replacement for callbacks.
specify, queue, and execute requests at different times. A Command object can have a lifetime independent of the original request. If the receiver of a request can be represented in an address space-independent way, then you can transfer a command object for the request to a different process and fulfill the request there.
support undo. The Command's execute operation can store state for reversing its effects in the command itself. The Command interface must have an added unexecute operation that reverses the effects of a previous call to execute. Executed commands are stored in a history list. Unlimited-level undo and redo is achieved by traversing this list backwards and forwards calling unexecute and execute, respectively.
support logging changes so that they can be reapplied in case of a system crash. By augmenting the Command interface with load and store operations, you can keep a persistent log of changes. Recovering from a crash involves reloading logged commands from disk and reexecuting them with the execute operation.
structure a system around high-level operations built on primitives operations. Such a structure is common in information systems that support transactions. A transaction encapsulates a set of changes to data. The Command pattern offers a way to model transactions. Commands have a common interface, letting you invoke all transactions the same way. The pattern also makes it easy to extend the system with new transactions.
Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
Model simple and complex components in such a way as to allow client entities to consume their behavior in the same way. The Composite Design Pattern captures hierarchical relationships of varying complexity and structure.
Simple component - a single class, also called a "Leaf"
Complex component - a class that contains pointers to sub-ordinate or "child" instances, and may delegate some or all of its responsibilities to them. These child instances may be simple or complex themselves. Also called a "Node".
Use the Composite pattern when:
you want to represent part-whole hierarchies of objects.
you want clients to be able to ignore the difference between compositions of objects and individual objects. Clients will treat all objects in the composite structure uniformly.
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
The Decorator Pattern works by wrapping the new "decorator" object around the original object, which is typically achieved by passing the original object as a parameter to the constructor of the decorator, with the decorator implementing the new functionality. The interface of the original object needs to be maintained by the decorator.
Decorators are alternatives to subclassing. Subclassing adds behaviour at compile time whereas decorators provide a new behaviour at runtime.
This difference becomes most important when there are several independent ways of extending functionality. In some object-oriented programming languages, classes cannot be created at runtime, and it is typically not possible to predict what combinations of extensions will be needed at design time. This would mean that a new class would have to be made for every possible combination. By contrast, decorators are objects, created at runtime, and can be combined on a per-use basis. An example of the decorator pattern is the Java I/O Streams implementation.
to add responsibilities to individual objects dynamically and transparently, that is, without affecting other objects.
for responsibilities that can be withdrawn.
when extension by subclassing is impractical. Sometimes a large number of independent extensions are possible and would produce an explosion of subclasses to support every combination. Or a class definition may be hidden or otherwise unavailable for subclassing.
Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use.
Structuring a system into subsystems helps reduce complexity. A common design goal is to minimize the communication and dependencies between subsystems. One way to achieve this goal is to introduce a Façade object that provides a single, simplified interface to the more general facilities of a subsystem.
Provide a simplified, improved, or more object-oriented interface to a sub-system that is overly complex (or may simply be more complex than is needed for the current use), poory designed, a decayed legacy system, or otherwise inappropriate for the system consuming it. Façade allows for the re-use of a valuable sub-system without coupling to the specifics of its nature.
A Façade is an object that provides a simplified interface to a larger body of code, such as a class library. A Façade can:
make a software library easier to use and understand, since the Façade has convenient methods for common tasks.
make code that uses the library more readable, for the same reason.
reduce dependencies of outside code on the inner workings of a library, since most code uses the Façade, thus allowing more flexibility in developing the system.
wrap a poorly designed collection of APIs with a single well-designed API.
Use the Façade pattern when:
you want to provide a simple interface to a complex subsystem. Subsystems often get more complex as they evolve. Most patterns, when applied, result in more and smaller classes. This makes the subsystem more reusable and easier to customize, but it also becomes harder to use for clients that don't need to customize it. A Façade can provide a simple default view of the subsystem that is good enough for most clients. Only clients needing more customizability will need to look beyond the Façade.
there are many dependencies between clients and the implementation classes of an abstraction. Introduce a Façade to decouple the subsystem from clients and other subsystems, thereby promoting subsystem independence and portability.
you want to layer your subsystems. Use a Façade to define an entry point to each subsystem level. If subsystems are dependent, then you can simplify the dependencies between them by making them communicate with each other solely through their Façades.
Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.
Use the Factory Method pattern when:
a class can't anticipate the class of objects it must create.
a class wants its subclasses to specify the objects it creates.
classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate.
Use sharing to support large numbers of fine-grained objects efficiently.
A Flyweight is a shared object that can be used in multiple contexts simultaneously. The Flyweight acts as an independent object in each context - it's indistinguishable from an instance of the object that's not shared. Flyweights cannot make assumptions about the context in which they operate. The key concept here is the distinction between intrinsic and extrinsic state. Intrinsic state is stored in the flyweight; it consists of information that's independent of the flyweight's context, thereby making it sharable. Extrinsic state depends on and varies with the flyweight's context and therefore can't be shared. Client objects are responsible for passing extrinsic state to the flyweight when it needs it.
A Flyweight is an object that minimizes memory occupation by sharing as much data as possible with other similar objects; it is a way to use objects in large numbers when a simple representation would use an unacceptable amount of memory. Often some parts of the object state cannot be shared and it's common to put them in external data structures and pass them to the flyweight objects temporarily when they are used.
The Flyweight pattern's effectiveness depends heavily on how and where it's used. Apply the Flyweight pattern when ALL of the following are true:
An application uses a large number of objects.
Storage costs are high because of the sheer quantity of objects.
Most object state can be made extrinsic.
Many groups of objects may be replaced by relatively few shared objects once extrinsic state is removed.
The application doesn't depend on object identity. Since flyweight objects may be shared, identity tests will return true for conceptually distinct objects.
Given a language, define a represention for its grammar along with an interpreter that uses the representation to interpret sentences in the language.
If a particular kind of problem occurs often enough, then it might be worthwhile to express instances of the problem as sentences in a simple language. Then you can build an interpreter that solves the problem by interpreting these sentences.
Use the Interpreter Pattern when there is a language to interpret, and you can represent statements in the language as abstract syntax trees. The Interpreter Pattern works best when:
the grammar is simple. For complex grammars, the class hierarchy for the grammar becomes large and unmanageable. Tools such as parser generators are a better alternative in such cases. They can interpret expressions without building abstract syntax trees, which can save space and possibly time.
efficiency is not a critical concern. The most efficient interpreters are usually not implemented by interpreting parse trees directly but by first translating them into another form. For example, regular expressions are often transformed into state machines. But even then, the translator can be implemented by the Interpreter pattern, so the pattern is still applicable.
Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
An aggregate object such as a list should give you a way to access its elements without exposing its internal structure. Moreover, you might want to traverse the list in different ways, depending on what you want to accomplish. But you probably don't want to bloat the List interface with operations for different traversals, even if you could anticipate the ones you will need. You might also need to have more than one traversal pending on the same list.
The Iterator pattern lets you do all this. The key idea in this pattern is to take the responsibility for access and traversal out of the list object and put it into an iterator object. The Iterator class defines an interface for accessing the list's elements. An iterator object is responsible for keeping track of the current element; that is, it knows which elements have been traversed already.
Use the Iterator pattern:
to access an aggregate object's contents without exposing its internal representation.
to support multiple traversals of aggregate objects.
to provide a uniform interface for traversing different aggregate structures (that is, to support polymorphic iteration).
Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
Object-oriented design encourages the distribution of behavior among objects. Such distribution can result in an object structure with many connections between objects; in the worst case, every object ends up knowing about every other.
Though partitioning a system into many objects generally enhances reusability, proliferating interconnections tend to reduce it again. Lots of interconnections make it less likely that an object can work without the support of others - the system acts as though it were monolithic. Moreover, it can be difficult to change the system's behavior in any significant way, since behavior is distributed among many objects. As a result, you may be forced to define many subclasses to customize the system's behavior.
You can avoid these problems by encapsulating collective behavior in a separate Mediator object. A mediator is responsible for controlling and coordinating the interactions of a group of objects. The Mediator serves as an intermediary that keeps objects in the group from referring to each other explicitly. The objects only know the Mediator, thereby reducing the number of interconnections.
Use the Mediator Design Pattern when:
a set of objects communicate in well-defined but complex ways. The resulting interdependencies are unstructured and difficult to understand.
reusing an object is difficult because it refers to and communicates with many other objects.
a behavior that's distributed between several classes should be customizable without a lot of subclassing.
Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later.
Sometimes it's necessary to record the internal state of an object. This is required when implementing checkpoints and undo mechanisms that let users back out of tentative operations or recover from errors. You must save state information somewhere so that you can restore objects to their previous states. But objects normally encapsulate some or all of their state, making it inaccessible to other objects and impossible to save externally. Exposing this state would violate encapsulation, which can compromise the application's reliability and extensibility.
We can solve this problem with the Memento pattern. A memento is an object that stores a snapshot of the internal state of another object - the memento's originator. The undo mechanism will request a memento from the originator when it needs to checkpoint the originator's state. The originator initializes the memento with information that characterizes its current state. Only the originator can store and retrieve information from the memento - the memento is "opaque" to other objects.
Use the Memento Design Pattern when:
a snapshot of (some portion of) an object's state must be saved so that it can be restored to that state later, AND
a direct interface to obtaining the state would expose implementation details and break the object's encapsulation.
Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
An event can occurs and a number of entities need to receive a message about it. When the event will occur, and perhaps if it will occur at all is unpredictable. Also, the number of entities, and which entities they are, is unpredictable. Ideally, the subscribers to this notification should be configurable at runtime.
A common side-effect of partitioning a system into a collection of cooperating classes is the need to maintain consistency between related objects. You don't want to achieve consistency by making the classes tightly coupled, because that reduces their reusability.
The Observer Design Pattern describes how to establish these relationships. The key objects in this pattern are subject and observer. A subject may have any number of dependent observers. All observers are notified whenever the subject undergoes a change in state. In response, each observer will query the subject to synchronize its state with the subject's state.
This kind of interaction is also known as publish-subscribe. The subject is the publisher of notifications. It sends out these notifications without having to know who its observers are. Any number of observers can subscribe to receive notifications.
Use the Observer Design Pattern in ANY of the following situations:
When an abstraction has two aspects, one dependent on the other. Encapsulating these aspects in separate objects lets you vary and reuse them independently.
When a change to one object requires changing others, and you don't know how many objects need to be changed.
When an object should be able to notify other objects without making assumptions about who these objects are. In other words, you don't want these objects tightly coupled.
Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.
A Prototype Design Pattern is a creational design pattern used in software development when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. This pattern is used for example when the inherent cost of creating a new object in the standard way (e.g., using the 'new' keyword) is prohibitively expensive for a given application.
To implement the pattern, declare an abstract base class that specifies a pure virtual clone() method. Any class that needs a "polymorphic constructor" capability derives itself from the abstract base class, and implements the clone() operation.
The client, instead of writing code that invokes the "new" operator on a hard-wired class name, calls the clone() method on the prototype, calls a factory method with a parameter designating the particular concrete derived class desired, or invokes the clone() method through some mechanism provided by another design pattern.
Use the Prototype Design Pattern when a system should be independent of how its products are created, composed, and represented; AND
when the classes to instantiate are specified at run-time, for example, by dynamic loading; OR
to avoid building a class hierarchy of factories that parallels the class hierarchy of products; OR
when instances of a class can have one of only a few different combinations of state. It may be more convenient to install a corresponding number of prototypes and clone them rather than instantiating the class manually, each time with the appropriate state.
Provide a surrogate or placeholder for another object to control access to it.
A proxy, in its most general form, is a class functioning as an interface to another thing. The other thing could be anything: a network connection, a large object in memory, a file, or some other resource that is expensive or impossible to duplicate.
Proxy Design Pattern is applicable whenever there is a need for a more versatile or sophisticated reference to an object than a simple pointer. Here are several common situations in which the Proxy pattern is applicable:
A remote proxy provides a local representative for an object in a different address space.
A virtual proxy creates expensive objects on demand.
A protection proxy controls access to the original object. Protection proxies are useful when objects should have different access rights.
A smart reference is a replacement for a bare pointer that performs additional actions when an object is accessed (counting the number of references, loading a persistent object into memory when it's first referenced, checking that the real object is locked).
Ensure a class only has one instance, and provide a global point of access to it.
The singleton pattern is a design pattern that is used to restrict instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system:
Use the Singleton Design Pattern when:
there must be EXACTLY ONE instance of a class, and it must be accessible to clients from a well-known access point.
when the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code.
Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.
The key idea in this pattern is to introduce an abstract class to represent the possible states of the object. This class declares an interface common to all the classes that represent different operational states. The concrete subclasses implement state-specific behavior. Based on the current state, the appropriate concrete class is selected and used.
Use the State Design Pattern in either of the following cases:
An object's behavior depends on its state, and it must change its behavior at run-time depending on that state.
Operations have large, multipart conditional statements that depend on the object's state. This state is usually represented by one or more enumerated constants. Often, several operations will contain this same conditional structure. The State pattern puts each branch of the conditional in a separate class. This lets you treat the object's state as an object in its own right that can vary independently from other objects.
Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
A single behavior with varying implementation exists, and we want to decouple consumers of this behavior from any particular implementation. We may also want to decouple them from the fact that the implementation is varying at all.
Use the Strategy Design Pattern when:
many related classes differ only in their behavior. Strategies provide a way to configure a class with one of many behaviors.
you need different variants of an algorithm. For example, you might define algorithms reflecting different space/time trade-offs. Strategies can be used when these variants are implemented as a class hierarchy of algorithms.
an algorithm uses data that clients shouldn't know about. Use the Strategy pattern to avoid exposing complex, algorithm-specific data structures.
a class defines many behaviors, and these appear as multiple conditional statements in its operations. Instead of many conditionals, move related conditional branches into their own Strategy class.
Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.
A Template Method defines the program skeleton of an algorithm. The algorithm itself is made abstract, and the subclasses override the abstract methods to provide concrete behavior.
First a class is created that provides the basic steps of an algorithm design. These steps are implemented using abstract methods. Later on, subclasses change the abstract methods to implement real actions. Thus the general algorithm is saved in one place but the concrete steps may be changed by the subclasses.
The Template Method thus manages the larger picture of task semantics, and more refined implementation details of selection and sequence of methods. This larger picture calls abstract and non-abstract methods for the task at hand. The non-abstract methods are completely controlled by the Template Method. The expressive power and degrees of freedom occur in abstract methods that may be implemented in subclasses. Some or all of the abstract methods can be specialized in the subclass, the abstract method is the smallest unit of granularity, allowing the writer of the subclass to provide particular behavior with minimal modifications to the larger semantics. In contrast the Template Method need not be changed and is not an abstract operation and thus may guarantee required steps before and after the abstract operations. Thus the Template Method is invoked and as a consequence the subordinate non-abstract methods and abstract methods are called in the correct sequence.
The Template Method pattern should be used:
to implement the invariant parts of an algorithm once and leave it up to subclasses to implement the behavior that can vary.
when common behavior among subclasses should be factored and localized in a common class to avoid code duplication. This is a good example of "refactoring to generalize". You first identify the differences in the existing code and then separate the differences into new operations. Finally, you replace the differing code with a template method that calls one of these new operations.
to control subclasses extensions. You can define a template method that calls "hook" operations at specific points, thereby permitting extensions only at those points.
Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.
The Visitor Design Pattern is a way of separating an algorithm from an object structure. A practical result of this separation is the ability to add new operations to existing object structures without modifying those structures.
The idea is to use a structure of element classes, each of which has an accept() method that takes a visitor object as an argument. Visitor is an interface that has a visitXXX() method for each element class. The accept() method of an element class calls back the visitXXX() method for its class. Separate concrete visitor classes can then be written that perform some particular operations:
A client that uses the Visitor pattern must create a ConcreteVisitor object and then traverse the object structure, visiting each element with the visitor.
When an element is visited, it calls the Visitor operation that corresponds to its class. The element supplies itself as an argument to this operation to let the visitor access its state, if necessary.
Use the Visitor Design Pattern when:
an object structure contains many classes of objects with differing interfaces, and you want to perform operations on these objects that depend on their concrete classes.
many distinct and unrelated operations need to be performed on objects in an object structure, and you want to avoid "polluting" their classes with these operations. Visitor lets you keep related operations together by defining them in one class. When the object structure is shared by many applications, use Visitor to put operations in just those applications that need them.
the classes defining the object structure rarely change, but you often want to define new operations over the structure. Changing the object structure classes requires redefining the interface to all visitors, which is potentially costly. If the object structure classes change often, then it's probably better to define the operations in those classes.