Los porqués y cuandos para patrones de diseño en PHP

Hay un montón de artículos que explican qué son los patrones de diseño, y cómo ponerlas en práctica, la web no tiene todavía otro de esos artículos! En su lugar, en este artículo, vamos a discutir más el cuando ypor qué , en lugar de la que y cómo .

Voy a presentar diferentes situaciones y casos de uso para los patrones, y también proporcionará definiciones cortas para ayudar a aquellos de ustedes que no están tan familiarizados con estos patrones específicos. Vamos a empezar.

Utilice un patrón de la fábrica

El patrón de la fábrica se inventó para ayudar a los programadores organizar la información relativa a la creación de objetos. Objetos veces tienen muchos parámetros del constructor, en otras ocasiones, se debe llenarse con información predeterminada inmediatamente después de su creación. Estos objetos deben ser creados en las fábricas, manteniendo toda la información relativa a su creación e inicialización contenido en un solo lugar.

Cuando se utilice un patrón de fábrica cuando se encuentre escribiendo código para reunir la información necesaria para crear objetos.

Por qué: Las fábricas ayudan a contener la lógica de la creación de objetos en un solo lugar.También pueden romper dependencias para facilitar el acoplamiento suelto y la inyección de dependencia para permitir un mejor análisis.

El patrón de puerta de enlace

Este patrón define un canal de comunicación entre una solución de persistencia y la lógica de negocio.Para aplicaciones más sencillas, se puede recuperar o recrear objetos completos por sí mismo, sino la creación de objetos es la responsabilidad de las fábricas en la mayoría de aplicaciones complejas.Gateways simplemente recuperar y conservar los datos en bruto.

Cuándo: Cuando usted necesita para recuperar o conservar la información.

Por qué: Ofrece una interfaz sencilla pública para las operaciones de persistencia complicados. También encapsula conocimiento persistencia y la lógica de negocios desacopla de la lógica de persistencia.

De hecho, el patrón de puerta de enlace es sólo una implementación particular de otro patrón de diseño que vamos a discutir en breve: el patrón del adaptador.

Vaya con el Proxy

Hay momentos en los que no pueden (o no quieren) exponer el conocimiento de la capa de persistencia a las clases de su negocio. El patrón de poder es una buena manera de engañar a sus clases de negocios en el pensamiento de que están utilizando objetos ya existentes.

Cuándo: Usted tiene que recuperar información de una capa de persistencia o una fuente externa, pero no quiere que su lógica de negocio para saber esto.

Por qué: Para ofrecer un enfoque no invasivo para la creación de objetos detrás de las escenas. También se abre la posibilidad de recuperar estos objetos sobre la marcha, perezosamente, y de diferentes fuentes.

La representación efectiva implementa la misma interfaz que un objeto real e imita su funcionalidad. La lógica de negocio simplemente se utiliza como si fuera un objeto real, pero de hecho, el proxy crea el objeto si no existe uno.

Conecte un adaptador

El patrón adaptador simplemente se crea una correspondencia entre la lógica de negocio y algo más. Ya hemos visto un patrón en acción: el patrón de puerta de enlace.

Cuándo: Es necesario crear una conexión con un módulo de pre-existente y cambiar potencialmente, una biblioteca o API.

Por qué: Para que la lógica empresarial a confiar sólo en los métodos públicos del adaptador ofrece, y permite el cambio del otro lado del adaptador fácilmente.

Si cualquiera de los modelos anteriores no se ajuste a su situación, entonces usted podría usar ...

El patrón de puente

Este es un patrón muy complicado. Yo personalmente no me gusta porque por lo general es más fácil tomar un enfoque diferente. Pero para aquellos casos especiales, cuando otras soluciones fallen, se puede considerar el patrón de puente.

Cuándo: El patrón adaptador no es suficiente, y que cambiar de clase en ambos lados de la tubería.

Por qué: Para ofrecer una mayor flexibilidad a costa de una complejidad considerable.

O acepte una visitantes

Si su problema de extender la funcionalidad es diferente - por ejemplo, usted tiene un complejo árbol-como la estructura de los objetos, y desea agregar funcionalidad a muchos nodos a la vez - una iteración simple no es posible, pero un visitante podría ser una solución viable. La desventaja, sin embargo, es que un patrón de aplicación visitante requiere una modificación a la vieja clase si no se ha diseñado para aceptar un visitante.

Cuándo: Un decorador no es adecuada y cierta complejidad adicional es aceptable.

Por qué: Para que organizó y enfoque para definir la funcionalidad de varios objetos, pero a costa de una mayor complejidad.