Patrones de diseño en PHP. Introducción


Patrones de diseño en PHP. Introducción

Breve introducción a los patrones de diseño para preparar algunos ejemplos enfocados en PHP.



Introducción

Desde la aparición de la Reusabilidad como característica propia de calidad de software (o quizás antes) la programación se ha ido desarrollando bajo este concepto, en donde librerías o bibliotecas (independientes del lenguaje que se han escrito) ya probadas y documentadas se pueden usar en cualquier proyecto. Sin ir más lejos, PHP, JAVA y C# están compuestos principalmente por librerías (de acceso a datos, de matemáticas, para manejar arreglos, etc.) desde las que podemos llamar a sus clases y funciones sin más que importar esa librería con una simple línea de código.
La Reusabilidad no es propia de la programación orientada a objetos pero es esta quien le saca el mejor provecho.

Designing object-oriented software is hard, and designing reusable object-oriented software is even harder.:

The Gang of Four


Lo anterior estaba bien, pero la Reusabilidad no solucionaba de igual manera problemas comunes dentro de aplicaciones similares (Por ejemplo, el menú de una aplicación no tiene que ver con el menú de otra aplicación). Pues entonces aparecen los patrones de diseño como soluciones a problemas recurrentes en el desarrollo de un software. Estos patrones de diseño, denominados así por The Gang of Four (1994), facilitan la reutilización de elementos de diseño que han tenido éxito en otras aplicaciones.

The Gang of Four

La banda de los cuatro se formo en principio por Erich Gamma y Richard Helm quienes se conocieron en la conferencia sobre programación orientada a objetos de Ottawa, Canada el año 1990, luego conocieron a Ralph Johnson y John Vlissides. Sacaron la primera versión del libro por el 10 de noviembre de 1994, en el cual reunieron y formalizaron los patrones de diseño mas conocidos y probados.
Erich Gamma
Richard Helm
Ralph Johnson
John Vlissides

Que es un Patrón de Diseño

Hay mucha información en la web y en libros sobre el tema lo que hace que no exista una definición como tal para cada tipo y que esta sea subjetiva.

Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, y luego describe el núcleo de la solución a ese problema, de tal manera que puede usar esta solución un millón de veces, sin hacerlo nunca de la misma manera dos veces.:

Christopher Alexander


Sin embargo, debemos tener presente los siguientes elementos para entender un patrón y sobre todo para la elección de uno: su nombre, el problema (cuando aplicar un patrón), la solución (descripción abstracta del problema) y las consecuencias (costos y beneficios en el desarrollo).
En relación a las consecuencias, el uso de un patrón mejora la calidad de software en cuanto a su flexibilidad y portabilidad así como también en eficiencia, uso de memoria, tiempo de ejecución y seguridad.
Patrones de Diseño
Patrones de Diseño

The Gang Of Four decidió todo lo anterior, que cada patrón debía tener un buen nombre, debe tener sinónimos, asociar un problema (la intención, la motivación y la aplicabilidad) y la solución que viene dada por una estructura (Un diagrama de clases), sus participantes (explican el rol que juegan las clases del diagrama anterior), las colaboraciones (diagramas de secuencia que explican las relaciones entre los objetos), la implementación (o comentarios de variaciones según ciertos detalles), un código (que demuestra cómo se implementa sobre un ejemplo concreto), los usos reconocidos y en donde se implementa junto a los patrones relacionados a este.

Patrones de Diseño hay muchos y siguen apareciendo continuamente. El desarrollo de software, como disciplina, está en constante cambio y así también los problemas de diseño. Así que las herramientas que usamos para nuestros desarrollos también se van actualizando y mejorando en favor de estos cambios. ¿Cuantos hay? Repito, muchos y The Gang Of Four los clasifico en tres tipos, patrones de creación, patrones de comportamiento y patrones de estructura.

Patrones de Creación

Hace referencia a la creación de objetos dinámicamente
  • Abstract Factory. Crea una instancia de diferentes familias de clases.
  • Builder. Separa la construcción de objetos de su representación.
  • Factory Method. Crea una instancia de varias clases derivadas.
  • Prototype. Una instancia iniciada lista para ser copiada o clonada.
  • Singleton. Una clase de la que sólo puede existir una instancia.

Patrones de Comportamiento

Relaciona el comportamiento entre las clases y los objetos de la aplicación así como sus responsabilidades y la interacción entre ellas.
  • Chain Of Responsibility. Forma de pasar un request entre una cadena de objetos.
  • Command. Encapsula un command request como un objeto.
  • Interpreter. Forma de incluir elementos del lenguaje en un programa.
  • Iterator. Acceder a elementos de una colección de forma secuencial.
  • Mediator. Define una comunicación simplificada entre clases.
  • Memento. Captura y restaura el estado interno de un objeto.
  • Observer. Define una dependencia de uno a muchos entre los objetos.
  • State. Altera el comportamiento de un objeto.
  • Strategy. Encapsula un algoritmo dentro de una clase.
  • Template Method. Aplaza los pasos exactos de un algoritmo a una subclase.
  • Visitor. Define una nueva operación a una clase sin cambios.

Patrones de Estructura

Se preocupa de resolver problemas sobre la estructura de clases, su composición y la distribución de responsabilidades.
  • Adapter. Ajusta las interfaces de distintas clases para que coincidan.
  • Bridge. Separa la interface de un objeto de su implementación.
  • Composite. Una estructura en árbol de objetos simples y compuestos.
  • Decorator. Añade responsabilidades a objetos de forma dinámica.
  • Facade. Una clase simple que representa un subsistema entero.
  • Flyweight. Ligera instancia usada para que sea eficiente de compartir.
  • Proxy. Un objeto que representa a otro objeto.

Relaciones entre patrones de diseño
Relaciones entre patrones de diseño

Puedes encontrar los patrones originales acá junto a un muy buen dialogo basados en las criticas hacia el libro por aquellos años.
En su libro, ellos recomiendan empezar por los siguientes patrones, entre los paréntesis esta el número de pagina en que los encuentras.
  • Abstract Factory (pagina 87)
  • Factory Method (107)
  • Adapter (139)
  • Observer (293)
  • Composite (163)
  • Strategy (315)
  • Decorator (175)
  • Template Method (325)


Ultimas consideraciones

Entender los patrones de diseño no es sencillo de buenas a primera y como casi todo en la vida requiere practica, ademas es fundamental tener un conocimiento sobre el paradigma orientado a objetos y sus características principales como herencia, polimorfismo, abstracción y encapsulamiento.
Son independientes del lenguaje de programación y de su implementación y la responsabilidad cae sobre el desarrollador el cuando y como aplicar un patrón si lo necesita.

Como nota final, debo mencionar que existen patrones arquitectónicos y que conocemos como MVC (Modelo-Vista-Controlador), MVVM (Modelo-Vista-Vista-Modelo), MVP (Modelo-Vista-Presentador), etc. Estos patrones a diferencia de los patrones de diseño ofrecen una solución para organizar la jerarquía o estructura general de desarrollo de un software y están en un nivel mas alto en el desarrollo mismo.
Un framework, por ejemplo, se estructura según un patrón arquitectónico e implementa diversos patrones de diseño. El primero es casi siempre reconocible y los segundos se mantienen invisibles en el core del framework.

Los siguientes artículos relacionados con el estudio de patrones estarán basados en el libro y seguiremos la recomendación que han hecho para esto.
PD. Les dejo el código fuente que usare como base para ejemplificar los patrones.

Saludos y hasta el próximo articulo.

Etiquetas patrones diseño solid

Ultima actualización Miércoles 27 de Junio, 2018




Agregar Comentario