Los patrones son cool

¿Cuántas veces más te tenemos que decir que debes de dejar de querer reinventar una rueda? Bueno, no importa, te diremos que no lo hagas las veces que sean necesarias hasta que lo entiendas, ya lo hemos hecho con los ciclos de vida del software y hoy toca el turno a un tema especial: los patrones de diseño. Los patrones de diseño son unos de los temas de los que ya deberías de haber oído hablar pero si esto no ha pasado no te preocupes, de nuevo te salvaremos el semestre. Sin más, comencemos.

Ya hemos pasado por ahí



Sí, ya sabemos que sentirse único es lo de hoy, sobre todo cuando tu código compila después de 3 días sin poder dormir, te sientes el nuevo Alan Turing y estás listo para ser reconocido a nivel mundial por tu contribución a la Ciencia Computacional, pero... Mira, no me gusta pararle las cabras a las personas pero a ver... Revisemos un poco... Sí, tu problema ya lo había solucionado alguien. Y lo hizo mejor que tú al parecer. No te angusties, eso pasa todo el tiempo, realmente siento que seas tan iluso pero oye, la programación no es un tema nuevo y los años no pasan en vano, la mayoría de los problemas a los que te puedas enfrentar ya han sido solucionados.

Esta situación es muy recurrente pero lejos de frustrarte estoy más que convencido que esto te debería de alegrar, el que alguien ya haya solucionado tu problema particular es una ventana de oportunidad para implementarlo a tus condiciones y pisar el acelerador del desarrollo. A nadie le gusta ser el segundo lugar pero para esta solución en particular debemos de estar agradecidos de no haber sido los primeros. ¿Ya lo captaste? Sí, ya te expliqué a grandes rasgos qué es un patrón de diseño, ¿todavía no lo captas? Bueno, vamos mas lento. Un patrón de diseño son lecciones y estrategias que han sobrevivido a ese problema particular que tienes, la utilidad de estos son que al ser algo ya descubierto, los patrones de diseño pueden ser explotados y aplicarlos a tus propios proyectos.

¿Es real la realidad?

Bueno, tengo que aceptar que esa pregunta fue más bien para captar tu atención. La pregunta real es... ¿Es tu solución la mejor de todas? Bueno, con seguridad de puedo contestar que no, en serio, los patrones de diseño son soluciones que han sido probadas una y otra vez con éxito así que comienza a usarlos. La próxima vez que tengas conflictos existenciales después de resolver un problema preguntándote si esa es la mejor solución mejor utiliza ese tiempo para buscar un patrón de diseño que se acomode mejor a tu situación. ¿Qué? ¡Es cierto! ¡Aún no los conoces! Bueno, vamos allá.

Elige el que más te gusta




Lo primero es lo primero, ¿de qué va tu problema? Si aún no o has identificado te daré algunos minutos para que lo hagas.

...

Te sigo esperando.

...

¿Ya? Bueno, no importa, si todavía no lo identificas luego vuelves a leer este punto. Ahora te voy a presentar algunos de los patrones de diseño más relevantes.

Patrones estructurales

¿Relaciones entre clases? No hay problema. Estos patrones te facilitarán la vida cuando tengas problemas en abstraer un problema en clases o bien, cuando tengas problemas en qué principio de diseño OO utilizar.

  • Decorator: añade una funcionalidad extra a un objeto sin modificar el comportamiento del resto de objetos del mismo tipo.
  • Facade: objeto que crea una interfaz simplificada para tratar con otra parte del código más compleja, de tal forma que simplifica y aísla su uso. 
  • Flyweight: muchos objetos comparten uno solo con propiedades comunes para ahorrar memoria.
  • Proxy: clase que funciona como interfaz hacia cualquier otra cosa. 
  • Composite: Facilita la creación de estructuras de objetos en árbol, dóonde todos los elementos emplean una misma interfaz. 
  • Bridge: desacopla una abstracción de su implementación para que las dos puedan evolucionar de forma independiente. 
  • Adapter: permite a dos clases con diferentes interfaces trabajar entre ellas a través de un objeto intermedio con el que se comunican e interactúan.
Patrones creacionales

Como su nombre lo dicen ayudan en la creación de nuevos objetos de tal forma que el proceso sea desacoplado de la implementación del resto del sistema. 
  • Builder: separa la creación de un objeto complejo de su estructura. 
  • Factory Method: expone un método de creación delegando en las subclases las implementación de este método. 
  • Prototype: permite la creación de objetos basados en plantillas. Un nuevo objeto se crea a partir de la clonación de otro objeto. 
  • Singleton: limita a uno el número de instancias posibles de una clase determinada en un programa y proporciona acceso global a la misma. 
  • Abstract factory: se trata de una interfaz que delega la creación de muchos objetos relaciones entre sí sin necesidad de especificar en ningún momento cuáles son las implementaciones concretas.
  • Prototype: ¿Alguien dijo plantillas? Bueno, pues podrás crear objetos basados en estos. Un nuevo objeto se crea a partir de la clonación de otro objeto.
Patrones de comportamiento

Como su nombre lo dicen ayudan en la creación de nuevos objetos de tal forma que el proceso sea desacoplado de la implementación del resto del sistema. 
  • Iterator: se utiliza para recorrer elementos de forma secuencial. 
  • Chain of responsibility: evitar acoplar al emisor y receptor de una petición dado la posibilidad a varios receptores de consumirlo.
  • Command: son objetos que encapsulan una acción y los parámetros que necesitan ejecutarse.
  • Mediator: se trata de un objeto que encapsula cómo otro conjunto de objetos interactúan y se comunican entre sí.
  • Memento: este patrón otorga la capacidad de restaurar un objeto a un estado anterior. 
  • Observer: los objetos son capaces de suscribirse a una serie de eventos que otro objetivo ca a emitir y serán avisados cuando esto ocurra. 
  • Visitor:  permite separar el algoritmo de la estructura de datos que se utilizará para ejecutarlo.
  • Template method: especifica el esqueleto de un algoritmo, permitiendo a las subclases definir cómo implementan el comportamiento real.
  • Strategy: permite la selección del algoritmo que ejecuta cierta acción en tiempo de ejecución.
  • State: permite modificar la forma en que un objeto se conporta en tiempo de ejecución basándose en su estado interno.
  • Interpreter: define una representación para una gramática así como el mecanismo para evaluarla. 
Conclusiones


Recuerda que los patrones de diseño que tienen que ayudar a resolver problemas y no a causarlos así que la única forma de que no te provoquen una frustración por tener otro tema más que aprender. Primero compréndelo, razónalo y sobre todo practícalo. Una vez hayas hecho esto entonces ya puedes aplicarlos y refactorizar tus anteriores proyectos y hacerlos más presentables para tu portafolio. El último consejo que te daré es que los patrones de diseño no son librerías y por ende, no deberías de razonarlas del mismo modo. Sin más que decir... ¡Nos vemos a la vuelta! 

Recuerda que la información para este post la obtuve del libro Head First: Design Patterns y lo puedes conseguir desde aquí. Dale una revisada, realmente es muy cool. También visita el sitio web de devexperto que aunque es un sitio para Kotlin estoy seguro que sacarás algo de provecho del mismo. 

Comentarios

Entradas populares de este blog

Hagamos un breve repaso

El QQQ que no es malo

Jersey Shore