|
Ref.
|
Patrones de Diseño
|
Autor
|
Propósito
|
|
1
|
Abstract Factory |
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides |
Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
|
|
2
|
Adapter Class |
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides |
Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldnt otherwise because of incompatible interfaces. |
|
3
|
Adapter Object |
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides |
Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldnt otherwise because of incompatible interfaces. |
|
4
|
Blackboard |
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal |
The Blackboard architectural pattern is useful for problems for which no deterministic solution strategies are known. In Blackboard several specialized subsystems assemble their knowledge to build a possibility partial or approximate solution. |
| 5 |
Bridge |
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides |
Decouple an abstraction from its implementation so that the two can vary independently. |
| 6 |
Broker |
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal |
The Broker architectural pattern can be used to structure distributed software systems with decoupled components that interact by remote service invocations. A broker component is responsible for coordinating communication, such as forwarding requests, as well as for transmitting results and exceptions. |
| 7 |
Builder |
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides |
Separate the construction of a complex object from its representation so that the same construction process can create different representations. |
| 8 |
Chain of Responsability |
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides |
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. |
| 9 |
Client-Dispatcher-Server |
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal |
The Client-Dispatcher-Server design pattern introduces an intermediate layer between clients and servers, the dispatcher component. It provides location transparency by means of a name service, and hides the details of the establishment of the communication connection between clients and servers. |
| 10 |
Command |
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides |
Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. |
| 11 |
Command-Processor |
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal |
The Command Processor design pattern separates the request for a service from its execution. A command processor component manages requests as separate objects, schedules their execution, and provides additional services such as the storing of request objects for later undo. |
| 12 |
Composite |
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides |
Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. |
| 13 |
Decorator |
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides |
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. |
| 14 |
Facade |
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides |
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 user. |
| 15 |
Factory Method |
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides |
Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. |
| 16 |
Flyweight |
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides |
Use sharing to support large numbers of fine-grained objects efficiently. |
| 17 |
Forward-Receiver |
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal |
The Forwarder-Receiver design pattern provides transparent interprocess communication for software systems with a peer-to-peer interaction model. It introduces forwarders and receivers to decouple peers from the underlying communication mechanisms. |
| 18 |
Interpreter |
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides |
Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language. |
| 19 |
Iterator |
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides |
Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation. |
| 20 |
Layers |
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal |
The Layers architectural pattern helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction. |
| 21 |
Master-Slave |
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal |
The Master-Slave design pattern supports fault tolerance, parallel computation and computational accuracy. A master component distributes work to identical slave components and computes a final result from the results these slaves return. |
| 22 |
Mediator |
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides |
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. |
| 23 |
Memento |
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides |
Without violating encapsulation, capture and externalize an objects internal state so that the object can be restored to this state later. |
| 24 |
MicroKernel |
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal |
The Microkernel architectural pattern applies to software systems that must be able to adapt to changing system requirements. It separates a minimal functional core from extended functionality and customer-specific parts. The microkernel also serves as a socket for plugging in these extensions and coordinating their collaboration. |
| 25 |
Model-View-Controller |
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal |
The Model-View-Controller architectural pattern (MVC) divides an interactive application into three components. The model contains the core functionality and data. Views display information to the user. Controllers handle user input. Views and controllers together comprise the user interface. A change-propagation mechanism ensures consistency between the user interface and the model. |
| 26 |
Observer |
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides |
Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. |
| 27 |
Pipes and Filters |
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal |
The Pipes and Filters architectural pattern provides a structure for systems that process a stream of data. Each processing step is encapsulated in a filter component. Data is passed through pipes between adjacent filters. Recombining filters allows you to build families of related systems. |
| 28 |
Presentation-Abstraction-Control |
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal |
The Presentation-Abstraction-Control architectural pattern (PAC) defines a structure for interactive software systems in the form of a hierarchy of cooperating agents. Every agent is responsible for a specific aspect of the applications functionality and consists of three components: presentation, abstraction, and control. This subdivision separates the human-computer interaction aspects of the agent from its functional core and its communication with other agents. |
| 29 |
Prototype |
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides |
Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype. |
| 30 |
Proxy |
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides |
Provide a surrogate or placeholder for another object to control access to it. |
| 31 |
Publisher-Subscriber |
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal |
The Publisher-Subscriber design pattern helps to keep the state of cooperating components synchronized. To achieve this it enables one-way propagation of changes: one publisher notifies any number of subscribers about changes to its state. |
| 32 |
Reflection |
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal |
The Reflection architectural pattern provides a mechanism for changing structure and behavior of software systems dynamically. It supports the modification of fundamental aspects, such as type structures and function call mechanisms. In this pattern, an application is split into two parts. A meta level provides information about selected system properties and makes the software self-aware. A base level includes the application logic. Its implementation builds on the meta level. Changes to information kept in the meta level affect subsequent base-level behavior. |
| 33 |
Singleton |
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides |
Ensure a class only has one instance, and provide a global point of access to it. |
| 34 |
State |
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides |
Allow an object to alter its behavior when its internal state changes. The object will appear to change its class. |
| 35 |
Strategy |
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides |
Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. |
| 36 |
Template-Method |
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides |
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 algorithms structure. |
| 37 |
View-Handler |
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal |
The View Handler design pattern helps to manage all views that a software system provides. A view handler component allows clients to open, manipulate and dispose of views. It also coordinates dependencies between view and organizes their update. |
| 38 |
Visitor |
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides |
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 operate. |
| 39 |
Whole-Part |
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal |
The Whole-Part design pattern helps with the aggregation of components that together form a semantic unit. An aggregate component, the Whole, encapsulates its constituent components, the Parts, organizes their collaboration, and provides a common interface to its functionality. Direct access to the Parts is not possible. |