Patrones de Diseño (GOF)

Patrones de Diseño (GOF)

1. De Comportamiento

   • Command: En él se solicita una operación, encapsulando dicha petición en un objeto, de forma que no sea necesario conocer el contenido de la misma.
   • Memento : Permite volver a estados anteriores del sistema.
   • Template Method: Define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos, esto permite que las subclases redefinan ciertos pasos de un algoritmo sin cambiar su estructura.
   • Visitor: Permite definir nuevas operaciones sobre una jerarquía de clases sin modificar las clases sobre las que opera.
   • Observer: Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambie de estado se notifique y actualicen automáticamente todos los objetos que dependen de él.
   • Interpreter: Dado un lenguaje, define una gramática para dicho lenguaje, así como las herramientas necesarias para interpretarlo.
   • Mediator :Define un objeto que coordine la comunicación entre objetos de distintas clases, pero que funcionan como un conjunto.
   • Chain of Responsability: Permite establecer la línea que deben llevar los mensajes para que los objetos realicen la tarea indicada.
   • Iterator: Permite realizar recorridos sobre objetos compuestos independientemente de la implementación de estos.
   • State: Permite que un objeto modifique su comportamiento cada vez que cambie su estado interno.
   • Strategy: Permite disponer de varios métodos para resolver un problema y elegir cuál utilizar en tiempo de ejecución.

2. Estructurales

   • Bridge: El objetivo de este patrón es la separación (desacoplamiento) de una abstracción de su implementación, de tal forma que ambas puedan ser modificadas independientemente sin afectar la una a la otra. Sólo ofrece una estructura en la que relaciona interfaces a implementar.
   • Composite: El objetivo de este patrón es el de montar los objetos en una estructura de árbol para representarlos de una forma jerarquizada. De este modo, se podrán manejar de forma similar y uniforme, tanto los objetos individuales como los objetos compuestos.
   • Decorator: este nos permite añadir funcionalidades o responsabilidades a un objeto de forma dinámica, nos provee de una alternativa muy flexible a la creación de subclases para extender funcionalidades.
   • Facade: este nos ayuda a crear o nos provee de una interfaz unificada para manejar un conjunto de objetos en un subsistema. Este conoce los subsistemas implicados en el sistema global, accede a ellos y les envía las peticiones de los clientes.
   • Adapter: se utiliza para transformar una interfaz en otra, de tal modo que una clase que no pudiera utilizar la primera, haga uso de ella a través de la segunda.
   • Flyweight: Sirve para eliminar o reducir la redundancia cuando tenemos gran cantidad de objetos que contienen información idéntica, además de lograr un equilibrio entre flexibilidad y rendimiento (uso de recursos).
   • Proxy: Define una representación o sustituto de un objeto sin cambiar su interfaz.

3. Creacionales

   • Factory Method: centraliza en una clase constructora la creación de objetos de un subtipo de un tipo determinado, ocultando al usuario la diversidad de casos particulares que se pueden prever, para elegir el subtipo que crear. es un método público de creación de objetos de esa misma clase.
   • Singleton: El objetivo de este patrón es asegurarse de que de una clase solo existe una instancia y que esta es accesible desde cualquier parte de nuestra aplicación. Existen muchas clases para las cuales es importante tener únicamente una sola instancia que pueda ser utilizada en muchas partes diferentes del sistema.
   • Prototype: Este patrón tiene como objetivo la especificación de un tipo de objeto que será un prototipo para la creación de nuevos objetos copiando este, o mejor dicho, clonando este prototipo.
   • Abstrac Factory: se emplea para la creación de familias de clases. Lo que a todos los efectos es, crear una interfaz que nos permita la creación y utilización de objetos relacionados pero sin tener que definir ni especificar una clase concreta.
   • Builder: hace separación de la construcción de objetos complejos o compuestos de su representación de modo que el mismo proceso de construcción pueda crear diferentes representaciones. Se usa para evitar situaciones de acoplamiento (nivel de dependencia entre clases) y permite que tengamos diferentes representaciones de un objeto construido.