¡No podía faltar en este blog una explicación de los patrones de diseño! Este artículo hará de enlace y listado de los patrones de diseño básicos que existen, para que puedas ir a estudiar cada uno de ellos y entender cómo funcionan. Pero además, quería hablarte un poco de qué son los patrones y por qué pueden facilitarte tu día a día.
Si te flipa todo esto del diseño de software, patrones, principios… entonces no puedes perderte esta guía que he preparado para ti: Aprende de una vez por todas los Principios SOLID.
Con definiciones sencillas, formas de detectar cuándo los incumplimos, y ejemplos para entender cómo utilizarlos en tus proyectos.
¿Qué son los patrones de diseño?
Hay una cosa que está clara: por muy específico que sea un problema al que te estés enfrentando durante el desarrollo de tu software, hay un 99% de posibilidades (cifra totalmente inventada, pero seguro que muy real) de que alguien se haya enfrentado a un problema tan similar en el pasado, que se pueda modelar de la misma manera.
Con modelado me estoy refiriendo a que la estructura de las clases que conforma la solución de tu problema puede estar ya inventada, porque estás resolviendo un problema común que otra gente ya ha solucionado antes. Si la forma de solucionar ese problema se puede extraer, explicar y reutilizar en múltiples ámbitos, entonces nos encontramos ante un patrón de diseño de software.
Un patrón de diseño es una forma reutilizable de resolver un problema común. Clic para tuitearEl concepto de patrón de diseño lleva existiendo desde finales de los 70, pero su verdadera popularización surgió en los 90 con el lanzamiento del libro de Design Pattern de la Banda de los Cuatro (Gang of Four), que aunque parezca que estamos hablando de los Trotamúsicos, es el nombre con el que se conoce a los creadores de este libro: Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides. En él explican 23 patrones de diseño, que desde entonces han sido un referente.
¿Por qué son útiles los patrones de diseño?
Puede parecer una tontería, pero si no encuentras utilidad a las cosas acabarás por no usarlas. Los patrones de diseño son muy útiles por los siguientes motivos:
1. Te ahorran tiempo
Sé que te encantará encontrar una solución ingeniosa a un problema cuando estás modelando tu software, y es normal, a mí también me pasa. Como he comentado alguna vez, el desarrollo es un proceso casi artístico, y ese reto mental que supone revierte en una satisfacción personal enorme una vez que consigues un buen resultado.
Pero hay que ser sinceros: buscar siempre una nueva solución a los mismos problemas reduce tu eficacia como desarrollador, porque estás perdiendo mucho tiempo en el proceso. No hay que olvidar que el desarrollo de software también es una ingeniería, y que por tanto en muchas ocasiones habrá reglas comunes para solucionar problemas comunes.
Buscar siempre una nueva solución a los mismos problemas reduce tu eficacia como desarrollador. Clic para tuitearLos patrones de diseño atajan ese punto. Una vez los conozcas, contarás con un conjunto de “trucos”, de reglas, de herramientas muy probadas, que te permitirán solucionar la mayor parte de tus problemas de forma directa, sin tener que pensar en cómo de válidas son, o si puede haber una alternativa mejor.
2. Te ayudan a estar seguro de la validez de tu código
Un poco relacionado con lo anterior, siempre que creamos algo nuevo nos surge la duda de si realmente estamos dando con la solución correcta, o si realmente habrá una respuesta mejor. Y el tema es que es una duda muy razonable y que en muchos casos la respuesta sea la que no deseas: sí que hay una solución más válida, y has perdido tu valioso tiempo en implementar algo que, aunque funciona, podría haberse modelado mejor.
Los patrones de diseño son estructuras probadas por millones de desarrolladores a lo largo de muchos años, por lo que si eliges el patrón adecuado para modelar el problema adecuado, puedes estar seguro de que va a ser una de las soluciones más válidas (si no la que más) que puedas encontrar.
3. Establecen un lenguaje común
Todas las demás razones palidecen ante esta. Modelar tu código mediante patrones te ayudará a explicar a otras personas, conozcan tu código o no, a entender cómo has atajado un problema. Además ayudan a otros desarrolladores a comprender lo que has implementado, cómo y por qué, y además a descubrir rápidamente si esa era la mejor solución o no.
Los patrones de diseño establecen un lenguaje común entre todos los miembros de un equipo. Clic para tuitearPero también te servirá para sentarte con tus compañeros a pensar sobre cómo solucionar algo, y poneros de acuerdo mucho más rápido, explicar de forma más sencilla cuáles son vuestras ideas y que el resto lo comprenda sin ningún problema. Los patrones de diseño os ayudarán a ti y a tu equipo, en definitiva, a avanzar mucho más rápido, con un código más fácil de entender para todos y mucho más robusto.
¿Cómo identificar qué patrón encaja con tu problema?
Desafortunadamente, tengo malas noticias… Este es el punto más complicado, y la respuesta más evidente, que es también la que menos nos gusta, es que se aprende practicando. La experiencia es la única forma válida de ser más hábil detectando dónde te pueden ayudar los patrones de diseño.
Por supuesto, hay situaciones conocidas en las que un patrón u otro nos puede ayudar, y las iré comentando a lo largo de los artículos. Además te recomiendo que te leas el libro de Head First Design Patterns, en el que además de explicarte los patrones de forma muy amena, explican muy bien cómo usarlos en la vida real.
Pero a partir de ese punto estás solo. Necesitarás conocer qué tipo de problemas soluciona cada uno y descubrir cómo aplicarlo a casos concretos. Como comentaba en el artículo de los miedos, en este caso lo mejor que te puede pasar es que encuentres a un compañero que los domine y que te haga de mentor. Pégate a él y exprímelo hasta que tengas todo su conocimiento. En caso contrario, practica, practica y practica.
Listado de patrones de diseño
Este es el listado de los patrones de diseño más conocidos. Poco a poco iré escribiendo artículos sobre cada uno de ellos y los iré enlazando aquí. Es un proceso largo porque son muchos y quiero encontrar la mejor forma de explicarlos, pero llegará el día en que tengamos aquí un listado completo que te sirva de referencia.
Los patrones se dividen en distintos grupos según el tipo de problema que resuelven, a saber:
Patrones creacionales
Son los que facilitan la tarea de creación de nuevos objetos, de tal forma que el proceso de creación pueda ser desacoplado de la implementación del resto del sistema.
Los patrones creacionales están basados en dos conceptos:
- Encapsular el conocimiento acerca de los tipos concretos que nuestro sistema utiliza. Estos patrones normalmente trabajarán con interfaces, por lo que la implementación concreta que utilicemos queda aislada.
- Ocultar cómo estas implementaciones concretas necesitan ser creadas y cómo se combinan entre sí.
Los patrones creacionales más conocidos son:
- Abstract Factory: Nos provee una interfaz que delega la creación de un conjunto de objetos relacionados sin necesidad de especificar en ningún momento cuáles son las implementaciones concretas.
- Factory Method: Expone un método de creación, delegando en las subclases la implementación de este método.
- Builder: Separa la creación de un objeto complejo de su estructura, de tal forma que el mismo proceso de construcción nos puede servir para crear representaciones diferentes.
- Singleton: limita a uno el número de instancias posibles de una clase en nuestro programa, y proporciona un acceso global al mismo.
- Prototype: Permite la creación de objetos basados en “plantillas”. Un nuevo objeto se crea a partir de la clonación de otro objeto.
Patrones estructurales
Son patrones que nos facilitan la modelización de nuestros software especificando la forma en la que unas clases se relacionan con otras.
Los patrones estructurales especifican la forma en que unas clases se relacionan con otras. Clic para tuitearEstos son los patrones estructurales que definió la Gang of Four:
- 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.
- Bridge: Desacopla una abstracción de su implementación, para que las dos puedan evolucionar de forma independiente.
- Composite: Facilita la creación de estructuras de objetos en árbol, donde todos los elementos emplean una misma interfaz. Cada uno de ellos puede a su vez contener un listado de esos objetos, o ser el último de esa rama.
- Decorator: Permite añadir funcionalidad extra a un objeto (de forma dinámica o estática) sin modificar el comportamiento del resto de objetos del mismo tipo.
- Facade: Una facade (o fachada) es un 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. Un ejemplo podría ser crear una fachada para tratar con una clase de una librería externa.
- Flyweight: Una gran cantidad de objetos comparte un mismo objeto con propiedades comunes con el fin de ahorrar memoria.
- Proxy: Es una clase que funciona como interfaz hacia cualquier otra cosa: una conexión a Internet, un archivo en disco o cualquier otro recurso que sea costoso o imposible de duplicar.
Patrones de comportamiento
En este último grupo se encuentran la mayoría de los patrones, y se usan para gestionar algoritmos, relaciones y responsabilidades entre objetos.
Los patrones de comportamiento gestionan algoritmos, relaciones y responsabilidades entre objetos. Clic para tuitearLos patrones de comportamiento son:
- Command: Son objetos que encapsulan una acción y los parámetros que necesitan para ejecutarse.
- Chain of responsibility: se evita acoplar al emisor y receptor de una petición dando la posibilidad a varios receptores de consumirlo. Cada receptor tiene la opción de consumir esa petición o pasárselo al siguiente dentro de la cadena.
- Interpreter: Define una representación para una gramática así como el mecanismo para evaluarla. El árbol de sintaxis del lenguaje se suele modelar mediante el patrón Composite.
- Iterator: Se utiliza para poder movernos por los elementos de un conjunto de forma secuencial sin necesidad de exponer su implementación específica.
- Mediator: 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 va a emitir, y serán avisados cuando esto ocurra.
- State: Permite modificar la forma en que un objeto se comporta en tiempo de ejecución, basándose en su estado interno.
- Strategy: Permite la selección del algoritmo que ejecuta cierta acción en tiempo de ejecución.
- Template Method: Especifica el esqueleto de un algoritmo, permitiendo a las subclases definir cómo implementan el comportamiento real.
- Visitor: Permite separar el algoritmo de la estructura de datos que se utilizará para ejecutarlo. De esta forma se pueden añadir nuevas operaciones a estas estructuras sin necesidad de modificarlas.
Conclusión
Como ves, nos encontramos ante una lista muy variada de patrones que nos dan la oportunidad de crear nuestro código de manera mucho más sencilla con estructuras probadas y que funcionan. La mayor complejidad radica en saber cuándo utilizarlas, algo que nos dará la práctica.
Es lógico que sólo con la pequeña definición que he dado no termines de entender para qué sirven algunos, por eso iré creando artículos para cada uno donde hablar de ellos en profundidad.
Existen muchos otros patrones de diseño además de los que se definieron en el libro de Design Patterns de la Gang of Four, y que iré añadiendo a este listado en el caso de que los encuentre de utilidad.
Y a ti, ¿cuáles te parecen los patrones de diseño más útiles? ¿Ya los conocías todos? Cuéntame en los comentarios.
Recuerda!! No te vayas sin tu guía: Aprende de una vez por todas los Principios SOLID.
Con definiciones sencillas, formas de detectar cuándo los incumplimos, y ejemplos para entender cómo utilizarlos en tus proyectos.
Buen artículo, creo que la correcta utilización de patrones agiliza mucho tu trabajo y lo hace más legible por los demás.
A la espera de los siguientes artículos :).
Gracias! Es una tarea grande, pero prometo ir añadiendo patrones poco a poco.
Mvc es un patrón de diseño?
Hola Wilson. Ya está contestado un par de veces en los comentarios. Gracias!
Hola! mi hija estudia ingeniería de Sistemas y la enseñanza sobre patrones no es explícita y no saben en qué situaciones se deben aplicar. ¿Hay estrategias para saber que patrón utilizar en cada situación?.
En principio cada patrón debe especificar en qué situaciones se usa. Para empezar con patrones me gusta mucho este libro: https://amzn.to/3GFSerd
La verdad es que hay muchos que no conocía y que de hecho, ni consigo entender tras una primera lectura :P, así que esperaré con ganas esos artículos donde expliques algunos.
Por cierto, echo en falta el patrón de “Lazy loading” 🙂
Sólo he añadido los que salen en el libro de Design Patterns, si bien es cierto que ese se usa bastante. Pensaré en añadirlo en un futuro. Gracias!
Uno de los síndromes del que te ha faltado hablar es el de la patternitis aguda. Los patrones pueden de ser de gran ayuda y es conveniente aplicarlos siempre que se ajusten al problema, como bien has explicado. Pero hacer un uso desmesurado puede convertir al sistema de clases en un auténtico laberinto sin sentido y dotar al código de una complejidad que no hacía falta crear.
Buen post Antonio 🙂
Sí que es verdad, como todo lo que se habla en el blog, hay que usarlo cuando tenga sentido, no sólo porque sí. Gracias!
Cierto Josep. Al final, el patrón se puede convertir en un antipatrón y joderlo todo más en lugar de arregarlo 😛
No sé como vas a ir explicando los patrones, pero si que es verdad que sólo se aprenden mediante la práctica, no vale sólo con leerlos. Por eso, como sugerencia que no sé como de viable será, pondría cada semana un problema a resolver por los lectores (los de Head First Design Patterns podrían valer) sin decir con que patrón se puede solucionar, y a la semana siguiente pondría la solución con el patrón y ya lo explicaría.
Oye, pues no es mala idea… Tengo pensar cómo hacerlo (eso de escribir artículos a medias no me termina de convencer), pero igual alguna forma de ocultarlo y mostrarlo una vez solucionado o algo así. Gracias por la idea 🙂
Programo por afición y con la esperanza de hacerlo de modo profesional en algún momento, pero este tipo de artículos me hace ver todo lo que me queda por aprender.
Muchas gracias por tomarte el tiempo de ayudar con tus conocimientos.
Nada, a ti por leerlos!
Mientras incluyas patos y restaurantes en los ejemplos el éxito lo tienes asegurado! Jajaja. Hablando en serio, bien dicho está que la clave es practicar. El otro día utilicé un builder y me quedo la duda, este es el mejor pattern que puedo utilizar? Quizá puede estar bien mostrar nuestros propios ejemplos, hablar de ellos, encontrar mejoras, etc. Me he flipado con el tema, es un pelotazo, gran iniciativa!
El tema es que yo creo que nunca se puede estar 100% seguro de que el patrón es el adecuado. Seguramente aparezca una nueva feature que haga que tengas que replantearte tu solución. Pero bueno, ahí entra la refactorización, de la que también tendremos que hablar largo y tendido 😛
En la mayoría de los comentarios veo que se pide código para entender cada uno de los patrones… ¡Buenas noticias, no estáis solos! Justo estoy grabando una serie de screencasts con la @devscola y Xavi Gost para explicarlos. En primer lugar, grabamos una sesión implementando el patrón de referencia (siempre en TDD) y una segunda sesión en la que a partir de código en producción (código open source con tests) explicamos las tensiones que nos dicen cuando podemos aplicar el patrón en cuestión y realizamos los refactors oportunos que nos llevan hacia ese patrón, todo ello como ejemplo para saber cuándo y cómo implementarlos sobre nuestras bases de código. Podéis ver las dos sesiones del patrón Abstract Factory (https://www.youtube.com/watch?v=3d83lNwaPkw y https://www.youtube.com/watch?v=TZTIjJgCBRQ respectivamente), la primera sesión del Decorator (https://www.youtube.com/watch?v=SP4jpDsDHJA) y el código (https://github.com/devscola/DesignPatterns). ¡Estad atentos al canal que iremos publicando nuevos hasta completarlos todos!
Gracias por el aporte Pablo, un buen curro el que os marcáis desde la Devscola
Me ha parecido muy interesante el tema porque he empezado a indagar en los patrones y me interese por MVC ¿donde encaja este patrón?
El MVC es un patrón arquitectónico, que viene a ser como un patrón de software pero con un ámbito un poco más amplio. Por eso no aparece en el listado anterior. Pero me parece genial para empezar, porque ayuda a plantearse ciertas cosas en un desarrollo por el simple hecho de afectar a la arquitectura.
¡Felicidades, Antonio!
Por dos razones:
1 – Algo que no está directamente relacionado con el alcance de este artículo, pero de igual o mayor relevancia: está escrito de forma clara, comprensible y con buena ortografía y sintaxis.
2 – En lo que al tema del artículo se refiere, haces una buena exposición, sin sentar cátedra y, como bien dices,
[QUOTE]
lo mejor que te puede pasar es que encuentres a un compañero que los domine y que te haga de mentor. Pégate a él y exprímelo hasta que tengas todo su conocimiento. En caso contrario, practica, practica y practica.
[/QUOTE]
¡Gracias!
Gracias Henry! Sí, lo que ocurre con muchos de estos temas es que no se pueden dar unas reglas paso a paso para aplicar los conceptos, porque depende de muchos factores, y al final sólo la experiencia te da ese grado de seguridad de que lo estás aplicando correctamente.
A ver . . .
Los patrones de diseño se pueden aplaudir o criticar, reinventar o renombrar, el GoF puso esos 23 según un criterio, explicaron por qué lo hicieron y punto.
El problema es que después de un pionero siempre hay quien dice :
“Bah!!!… yo ya conocía eso… les falta aquí y les sobra allá”…
Y al dia siguiente va y publica un libro … o mejor dicho “EL LIBRO” de los patrones de diseño.
En el mejor de los casos quizá aclare algo de los más complejos, en el caso ideal puede aparecer algún genio como ‘Andrei Alexandrescu’ que vaya un paso mas allá si es que eso es posible…
…pero después de leer docenas de ‘Libros Definitivos’ con títulos rimbombantes como
‘Patrones de Diseño, la guía definitiva’…(¡Ja!)
‘Patrones de diseño optimizados para todos los usos ‘… ( ¿w.t.f.?)
o mi preferido…
’23 patrones para el éxito en solo 23 dias, ¿vas a ser el looser que no los domine?’…
¡CopyWriting en estado puro!…
La mayoría de esos ‘recocidos’ simplemente incluyen un apéndice de ultima hora diciendo :
“los patrones de diseño están genial esperamos que este libro ‘Como programar rutinas recursivas con Patrones de Diseño’ sea adquirido por todos aquellos que quieran dar un cambio de 180 grados al módico precio 75 € que cuesta porque el autor es un alma generosa que está comprometido en ayudar al prójimo.”
En resumen, primero vamos a aprender lo que es un patrón de diseño bien utilizado y luego podremos hablar mirando por encima del hombro.. personalmente diré que hace poco apliqué ‘Singleton’ (al que tenia por el menos interesante) en un programa de bases de datos super complejo y todavía estoy borrando código de más que tenia, aproximadamente un 35%… ufff!!!.
Desde entonces he dejado de menospreciar ‘Singleton’. Miedo me da cuando use dos patrones a la vez.
Perdón por la extensión.
y el patrón Repository ?
Ese aparece en otro libro, el de Patterns of Enterprise Application Architecture, también de Martin Fowler. Patrones hay muchísimos, aquí me he querido centrar sólo en los que aparecen en ese libro.
Entre los patrones creacionales el mas conocido y utilizado quizas es el patron MVC que no has mencionado, Saludos
Hola Lucho, en los comentarios ya se ha hablado de ese tema y ya da una respuesta a tu comentario.
Mas concretamente en la fecha (23 marzo, 2016).
Un saludo.