Patrón Composite: Prueba de integración
En esta lección del Curso de Patrones de Diseño vamos a diseñar la interfaz que queremos para nuestros objetos escribiendo para ello una prueba de integración con PHPUnit.
En esta lección del Curso de Patrones de Diseño vamos a diseñar la interfaz que queremos para nuestros objetos escribiendo para ello una prueba de integración con PHPUnit.
El patrón Composite nos brinda una manera elegante y sencilla de componer objetos de manera recursiva en una estructura de árbol en la cual cada objeto individual o grupo de objetos puede ser tratado de la misma manera dado que todos compartirán la misma interfaz base. Composite es también un excelente ejemplo de mezcla entre herencia y composición de objetos que aprendimos en el Curso de programación orientada a objetos con PHP. En el siguiente videotutorial veremos una pequeña introducción a este patrón de diseño estructural antes de comenzar a escribir código.
En lecciones anteriores aprendimos cómo usar el Patrón de Arquitectura Gateway en conjunto con «Service Stub» para encapsular y luego simular las dependencias en servicios externos. Una alternativa para probar una clase que dependa de un servicio externo es usar la técnica conocida como «Mocking» con la cual podemos reemplazar y emular el comportamiento de objetos reales con objetos falsos o «mocks».
Una ventaja de los mocks es que éstos nos permiten verificar que ciertos métodos esperados sean llamados, además nos permiten controlar los valores retornados por dichos métodos. Esta técnica es muy útil para reemplazar del todo el uso de servicios externos en nuestras pruebas, sin embargo no podemos confiarnos del uso de mocking al 100% como veremos en la lección siguiente.
Colapsar Jerarquía es una técnica de refactorización -explicada por Martin Fowler en su libro Refactoring- la cual nos invita a combinar una superclase y una subclase cuando éstas no sean muy diferentes entre sí. En esta lección aplicaremos esta técnica para combinar 4 clases en una sola.
Extraer Superclase es una de las técnicas de refactorización explicadas por Martin Fowler en su libro Refactoring. Con esta técnica vamos a Crear una superclase y mover las características comunes de dos o más clases hacia ésta. En esta lección aplicaremos esta refactorización para eliminar la duplicación de código de nuestras clases de Video
.
Service Stub es uno de los «Patrones de Arquitectura de Aplicaciones Empresariales» descrito por Martin Fowler. Este patrón nos permite remover la dependencia de servicios problemáticos durante nuestras pruebas. Estos servicios típicamente involucran la ejecución de tareas pesadas, llamados a API externos, etc.
En esta lección crearemos un Service Stub para la interfaz VideoGateway
que definimos en una lección anterior.
Adapter es uno de los patrones de diseño más simples. Un adaptador es una clase que provee un enlace entre dos clases o interfaces incompatibles entre sí para que puedan trabajar en conjunto.
En esta lección explicaré cómo lograr que diferentes implementaciones se mantengan uniformes con el apoyo de pruebas automatizadas.
En esta lección vamos a cumplir el «Principio de Inversión de Dependencia» de SOLID, mediante la creación de dos interfaces: Styde\Adapter\VideoAdapter
y Styde\Video
de las cuales van a depender tanto nuestros adaptadores como el resto del código de nuestro sistema.
En esta lección continuaremos aprendiendo cómo unificar clases provenientes de un API de terceros para facilitar su uso dentro de tu aplicación sin tener que comprometer la calidad de tu código.