The Factory abstract template provides an interface for creating families of related or dependent objects without specifying their specific classes. The client is separated from any specifics of a particular object obtained from the factory.
The adapter design pattern transforms the class interface into another interface that clients expect. The adapter allows classes to work together, which otherwise cannot be associated with incompatible interfaces. It separates the client from the target class.
The responsibility chain design template separates the request sender from its recipient, providing more than one object with the ability to process the request. The template combines the receiving objects and passes the request along the chain until the object processes it. Each object in the chain either processes the request or passes it to the next object in the chain.
The command design template encapsulates the request as an object, thereby allowing you to parameterize clients with various requests, queue or log requests, and support canceled operations. A request object associates one or more actions with a specific recipient. The command template separates the object sending the request from the objects that receive and execute this request.
A composite design pattern combines related objects into tree structures to represent the hierarchy of the whole. The template allows customers to equally process individual objects and composition of objects. The Composite pattern is part of the overall Model-View-Controller pattern.
The Decorator design pattern provides additional responsibility for the object dynamically. Decorators provide a flexible alternative to a subclass to extend functionality. Like subclassification, adaptation of the Decorator pattern allows you to introduce new behavior without modifying existing code. Decorators wrap an object of the class whose behavior they propagate. They implement the same interface as the object they are wrapping, and add their own behavior before or after delegating the task to the wrapped object. The Decorator pattern expresses the design principle that classes should be open for extension, but closed for modification.
The Facade design pattern provides a unified interface for a set of interfaces in a subsystem. The template defines a higher-level interface that simplifies the use of subsystems, reducing complexity and hiding the connection and dependencies between the subsystems.
The Iterator design pattern provides a way to access the elements of an aggregate object (i.e. collection) sequentially without exposing it to the underlying representation. An Iterator template transfers responsibility for accessing and moving collection elements from the collection itself to the iterator object. An iterator defines an interface for accessing items in the collection and tracks the current item. Different iterators can implement different bypass policies.
The Mediator design pattern defines an object that encapsulates how a set of objects interacts. The mediator promotes a free connection, preventing direct access of objects to each other, and allows you to independently change their interaction. Thus, these objects can remain more reusable. The "intermediary object" in this template centralizes the complex logic of communication and control between objects in the system. These objects inform the mediator object when their state changes and, in turn, responds to requests from the intermediary object.
The Memento template captures and externalizes the internal state of objects - without breaking encapsulation - so the object can be restored to that state later. The Memento template preserves the important state of a key object external to that object to maintain cohesion.
The Observer design pattern defines a one-to-many relationship between objects, so when one object changes state, all its dependents are notified and updated automatically. The Observer pattern is essentially a publishing and subscribing model in which the subject and its observers are loosely coupled. Communication can be made between observing and observable objects, without requiring much to learn about the other.
The proxy design pattern provides a surrogate or placeholder for another object to control access to this other object. This template is used to create a representative or proxy object that controls access to another object, which may be remote, expensive to create, or in need of provision. This pattern is structurally similar to the Decorator pattern, but it serves a different purpose; The decorator adds behavior to the object, while Proxy controls access to the object.
The reseller design pattern solves the general problem of redirecting an event that occurs in one application execution context to another execution context for processing. This is a hybrid model. Although not displayed in The Gang of Four, it combines the elements of the Command, Memo, and Proxy design patterns described in this book. This is also a variant of the Trampoline template (which also does not appear in the book); in this template, the event is initially accepted by the trampoline object, the so-called, because it immediately bounces or redirects the event to the target object for processing.
The Singleton design pattern ensures that the class has only one instance and provides a global access point to it. The class monitors a single instance and ensures that no other instance can be created. Single classes are suitable for situations when for one object it makes sense to provide access to a global resource.
The design pattern template pattern defines the skeleton of an algorithm in an operation, deferring some steps to subclasses. The template method template allows subclasses to redefine certain stages of the algorithm without changing the structure of the algorithms.
Source: Cocoa Design Patterns .