U a

Patrones de diseño de software

por Antonio Leiva | Software Craftmanship

¡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.

¿Qué son los patrones de diseño?

Hay una cosa que está clara: por muy especí co 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 re riendo 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 TUITEAR

El concepto de patrón de diseño lleva existiendo desde nales 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:
2
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 e cacia 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 TUITEAR

Los 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 TUITEAR

Pero 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 de nitiva, 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 identi韑�car 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 2

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:

1. 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.

2. Ocultar cómo estas implementaciones concretas necesitan ser creadas y cómo se combinan entre sí.

Los patrones creacionales facilitan la tarea de creación de nuevos
objetos encapsulando el proceso.  CLIC PARA TUITEAR

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 especi car 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 especi cando 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 TUITEAR

Estos son los patrones estructurales que de nió 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 modi car el
2
comportamiento del resto de objetos del mismo tipo.

Facade: Una facade (o fachada) es un objeto que crea una interfaz simpli cada para tratar con otra parte del código
más compleja, de tal forma que simpli ca 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 n 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 TUITEAR

Los 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: De ne 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í ca.

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 modi car 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: Especi ca el esqueleto de un algoritmo, permitiendo a las subclases de nir 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 modi carlas.

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 de nición que he dado no termines de entender para qué sirven algunos, por eso iré
2
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 de nieron 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.
 Author: Antonio Leiva
Soy un apasionado de Kotlin. Hace ya más de dos años que estudio el lenguaje y
su aplicación a Android para ayudarte a ti a aprenderlo de la forma más sencilla
posible.

 Twitter  Google+  Linkedin  Github

Compártelo:

     7

Relacionado

Convierte tu profesión en tu pasión Metodología para convertirte en un
desarrollador de éxito
18 Febrero, 2016
16 Junio, 2016
En "Autoconocimiento"
En "Hazte visible"
12 razones por las que usar Kotlin
para Android desde hoy (KDA 30)
3 Noviembre, 2016
En "Kotlin"

22 Comentarios
Juan el 8 Marzo, 2016 a las 10:46
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 :).

Responder

Antonio Leiva el 8 Marzo, 2016 a las 10:53

Gracias! Es una tarea grande, pero prometo ir añadiendo patrones poco a poco.

Responder

Pabloku el 8 Marzo, 2016 a las 17:57

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”
2
Responder

Antonio Leiva el 9 Marzo, 2016 a las 0:26

 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!

Responder

Josep V. el 8 Marzo, 2016 a las 18:29

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

Responder

Antonio Leiva el 9 Marzo, 2016 a las 0:27

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!

Responder

Pabloku el 8 Marzo, 2016 a las 18:56

Cierto Josep. Al nal, el patrón se puede convertir en un antipatrón y joderlo todo más en lugar de
arregarlo

Responder

Juan Carlos (@Jekopena) el 9 Marzo, 2016 a las 0:24

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.

Responder

Antonio Leiva el 9 Marzo, 2016 a las 0:30

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

Responder

Darío Alonso el 10 Marzo, 2016 a las 8:29

Programo por a ció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.

2
Responder

Antonio Leiva el 10 Marzo, 2016 a las 16:25

 Nada, a ti por leerlos!

Responder

Kilian Cerdán Ortiz el 10 Marzo, 2016 a las 13:19

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 ipado con el tema, es un pelotazo, gran iniciativa!

Responder

Antonio Leiva el 10 Marzo, 2016 a las 16:27

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

Responder

Pablo Guardiola el 12 Marzo, 2016 a las 14:02

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!

Responder

Antonio Leiva el 15 Marzo, 2016 a las 15:16

Gracias por el aporte Pablo, un buen curro el que os marcáis desde la Devscola

Responder

jose antonio sanchez robles el 21 Marzo, 2016 a las 13:52

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?

Responder

Antonio Leiva el 23 Marzo, 2016 a las 16:01

2
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.
 Responder

Henry GR el 6 Junio, 2016 a las 10:29

¡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 re ere, 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!

Responder

Antonio Leiva el 6 Junio, 2016 a las 10:33

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 nal
sólo la experiencia te da ese grado de seguridad de que lo estás aplicando correctamente.

Responder

Joaquín el 26 Junio, 2016 a las 19:41

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 De nitivos’ con títulos rimbombantes como

‘Patrones de Diseño, la guía de nitiva’…(¡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
2
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.

Responder

Christian Ramirez Castillo el 2 Noviembre, 2016 a las 20:58

y el patrón Repository ?

Responder

Antonio Leiva el 3 Noviembre, 2016 a las 8:51

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.

Responder

Trackbacks/Pingbacks

1. Presentación segunda temporada CodelyTV – Codely.TV - […] que le echéis un ojo al blog porque tiene material
bastante trabajado como por ejemplo este post sobre patrones de diseño […]

2. ¿Qué signi ca ser un Senior Developer? Teorías y realidades - […] fácil, le eché muchas horas para ponerme al día.
Empecé a hacer cursos, leer libros, aprender patrones de diseño,…

¿QUIERES APRENDER KOTLIN DESDE HOY?

Te regalo: "Crea tu primer proyecto Android con Kotlin en 15 minutos",

En ella aprenderás a conígurar Android Studio y escribir tus primeras líneas en nada de tiempo.

Nombre (sin apellidos)

Email 2
¡DESCÁRGALO YA!

Salúdame en Google+
Salúdame en Google+

Antonio Leiva

Seguir

1,935 seguidores

Tweets por  @devexperto1
Antonio [DevExperto] 
@devexperto1

Aún hay plazas para el sábado en Barcelona! #Kotlin para #AndroidDev presencial, con 
un descuento increíble. +info: devexperto.com/kotlin­desarro…

Insertar Ver en Twitter

Últimos artículos

Tú me lo has pedido: Kotlin para Desarrolladores Android… ¡Esta vez en streaming!

Lleva Realm al siguiente nivel con Kotlin

Análisis del 2016 y objetivos para el 2017

12 razones por las que usar Kotlin para Android desde hoy (KDA 30)

Cómo usar código Kotlin desde Java: empieza a usar Kotlin desde hoy (KDA 29)

Inicio Sobre mí Libro Curso Presencial Mentoring Contacto ¡GUÍA GRATIS!

Política de privacidad Política de cookies

 
Diseñado por Elegant Themes | Alojado por WebEmpresa