uso de patrones de diseño parte 2

Seguimos comentando patrones de diseño que nos ayudan a dar soluciones más simples sin necesidad de reinventar la rueda. En la primera parte ya vimos unos cuantos patrones, así que ahora seguimos

Singleton Pattern

Un objeto es Singleton si tiene un constructor privado y un método público getInstance() que asegura que solo existe una instancia del objeto. Es considerado a veces un antipatrón.

Cuando Es necesario lograr una sola instancia de un objeto

Por qué Para ofrecer un punto de acceso único cuando sea necesario

Aquí tenemos un ejemplo del patrón.

Adapter Pattern

Crea una correspondencia entre la lógica de negocio y algo más. Es bastante parecido a Gateway Pattern.

Cuando Es necesario crear una conexión con un módulo, una librería o API preexistente y «potencialmente» cambiante.

Por qué Para permitir que la logica de negocio solo confíe en los métodos públicos del adaptador

Aquí tenemos un ejemplo del patrón.

Bridge Pattern

Es un patrón complicado. Cuando otras soluciones no funcionan siempre se puede considerar el patrón bridge

Cuando El patrón Adapter no es suficiendte y se han cambiado las clases a ambos lados.

Por qué Para ofrecer mayor flexibilidad, pagan el precio de una significativa complejidad

Aquí tenemos un ejemplo del patrón.

Composite Pattern

Considere que tiene una secuencia de comandos con comandos similares, y que desea hacer una sola llamada para ejecutarlo. Es parecido a Active Object pero la diferencia recae en que al llamar a un método de un objeto Composite este llama a mismo método en todos sus objetos sin sacarlos de la lista. Los clientes están llamando a un método y piensan que solo están hablando con ese objeto en particular, pero de echo sus acciones se aplican a muchos,

Cuando Es necesaria aplicar una acción a varios objetos similares

Por qué para reducir la duplicación y simplificar como los objetos son llamados.

Aquí tenemos un ejemplo del patrón.

State Pattern

Una máquina de estados finitos(FSM) es una modelo que tiene un número finito de estados discretos. La implementación de un FSM puede ser difícil, y la manera más sencilla es hacer un switch. En cada uno de los caso se representa un estado actual de la maquina e indica como activar el siguiente estado.

Pero todos sabemos que switch muy grandes… son poco deseables debido a que producen una gran ramificación del código. Así que es mejor olvidarse de switch y utilizar el patrón State Es patrón state se compone de varios objetos: un objeto para coordinar las cosas, una interfaz que representa un estado abstracto , y luego varias implementaciones – una ara cada estado. Cada estado sabe que estado se produce después de él, y el estado puede notificar al objeto de coordinación para establecer su nuevo estado.

Cuando Se requiere implementar la lógica de FSM

Por qué Para eliminar los problemas de una sentencia switch y para encapsular mejor el significado de cada estado individual.

Un dispensador de alimentos podría tener una clase principal que tiene una referencia a una clase estado. Las clases de estado podrían ser algo así como WaitingForCoin, InsertedCoin, SelectedProduct, WaitingForConfirmation, DeliveringProduct, ReturningChange. Cada estado lleva a cabo su trabajo y crea el siguiente estado para enviar a la clase coordinadora.

Aquí tenemos un ejemplo del patrón.

Decorator Pattern

Hay momentos en los que se implementas clases o módulos para toda la aplicación, y no se puede modificar sin afectar de manera radical al sistema. Pero, al mismo tiempo, es necesario añadir nuevas funcionalidades que los usuarios requieren. El patrón decorador puede ayudar en estas situaciones. Es muy simple: tomar la funcionalidad existente y añadir nueva. Esto se logra mediante la ampliación de la clase original y proporciona nuevas funcionalidades en tiempo de ejecución. Clientes antiguos siguen utilizando el nuevo objeto como harían con la antigua, y los nuevos clientes pueden empezar a utilizar la nueva funcionalidad y/o la antigua.

Cuando No se puede cambiar una antigua clase, pero se necesitan implementar nuevos comportamientos o estados.

Por qué Ofrece una manera poco intrusiva de añadir nuevas funcionalidades.

Aquí tenemos un ejemplo del patrón.

Visitor Pattern

Si el problema es extender una funcionalidad existente – por ejemplo, se tiene una estructura compleja de tipo árbol de objetos y se desea añadir funcionalidad a muchos nodos a la vez. El patrón Visitor es una solución viable. La desventaja es que una aplicación visitor requiere modificar una clase «legacy» si no se ha diseñado para aceptar un visitante

Cuando El patrón Decorator no es adecuado y es posible añadir cierta complejidad adicional

Por qué Para permitir la separación de intereses

Aquí tenemos un ejemplo del patrón.

Conclusiones

Como ya dijimos, los patrones de diseño ayudan a resolver problemas, pero solo si los patrones se ajustan. No hay que abusar de ellos. En el anterior post ya enlazamos domnikl/DesignPatternsPHP y sourcemaking.com donde encontraremos patrones de diseño y antipatrones.