Introducción al origen del concepto SOLID para referirnos a los 5 principios expresados por Robert C. Martin

Un principio sencillo pero fundamental para la construcción de sistemas mantenibles. No crees clases con múltiples responsabilidades.

Con este video entenderas otro de los principios más referenciados en el campo de desarrollo del software: el open/closed principle.  Antes de empezar planteate la pregunta: ¿Cuando puedo decir que mi sistema está correctamente diseñado para ser extendido?

El principio de sustitución de Liskov es uno de los más importantes referidos al tema de la herencia. Veremos en que consiste y algunos casos importantes de violación.

Entendiendo y interiorizando este principio nuestro sistema será más facilmente reusable y evitaremos futuros problemas a nuestros clientes.

Principio que expone Martin para evitar la dependencia de módulos más generales a módulos más específicos.

Si estas con nosotros en el curso ya eres consciente de la importancia de entender los patrones de diseño y los beneficios que pueden reportarte, pero .... ¿conoces su historia? ¿Sabías que los orígenes son más cercanos a plazas y calles que a clases y métodos?

En lugar de dar una definición de lo que es un patrón de diseño, ¿que tal si creamos nosotros mismos  uno?

El abstract factory pattern nos ayuda en situaciones donde hay mucha variación en los tipos de objetos a crear según el entorno.

Olvídate de estas engorrosas e inusables clases con infinidad de contructores con el Builder pattern.

Con este pattern, podrás crear un acceso compartido para crear estructuras complejas y, al mismo tiempo, ofrecer la posibilidad de extender con nuevos subtipos tu aplicación sin modificar el código existente.

Sencilla, pero potente, idea para evitar duplicidades en nuestro código al crear objetos muy similares.

Esto no es un pattern ! ;-)  Aprovechamos la explicación del prototype pattern para hablar del método clone.

Es muy problable que ya conozcas lo que es un singlenton (si no lo conoces no te preocupes), pero: ¿sabrías implementar uno correctamente?

Tienes tu sistema bien programado y testeado y te piden que ahora te adaptes a una serie de interfaces externas. ¿Como puedes hacerlo siguiendo el principio open-closed?

Este pattern nos ayudará cuando necesitemos la mejor solución sea crear no una sola jerarquía sino dos, y extender un "puente" entre ellas. Mira bien este pattern: ¡No siempre es trivial saber donde nos puede ayudar!

Es curioso cuantas veces en programación una acción puede ser realizada sobre un solo objeto o una colección de ellos. Evita, con el composite pattern, duplicar la API y complicar a tu diseño en estos casos.

No quiero avanzar contenido, pero este API tiene efectos realmente espectaculares en la simplicidad que produce.

Has aplicado las recomendaciones generales de diseño y ahora tienes un conjunto de clases e interfaces muy coherentes. Cada una con su responsabilidad bien definida. Pero llega ahora los casos de uso complejos requieren trabajar con muchas de ellas. ¿Como podemos seguir con nuestro diseño modular y, al mismo tiempo, facilitar la vida a nuestros clientes?

¿Como podemos conseguir que nuestra aplicación tenga (o parezca tener) muchos objetos dependientes y, al mismo tiempo, haga un uso eficiente de los recursos (por ejemplo memoria)? Bienvenido al flyweight pattern. Y, por cierto, no estaremos solos: ¡También lo aplican los String de Java!

Añade un toque de seguridad a tus clases sin complicar la vida a los clientes. 

¿Habéis observado cierta similitud en muchos de los patrones estructurales? ¡Enhorabuena! Bienvenidos a la composición

¿Que vamos ha decir del chain of responsability si ya lo hemos descubierto nosotros mismos? Pues poco. Solo repasaremos lo fundamental de este patrón.

Con los lambda en el lenguaje ya podemos "pasar funciones" a métodos, asignarlos a variables etc. Pero si estamos usando una versión anterior a Java 8, o queremos una aproximación más orientada a objetos, el command pattern es fundamental.

Quizás el pattern más sofisticado. A veces la solución más flexible es crear un "lenguaje dentro del lenguaje". 

¿Quieres que tus clientes actuen sobre tu estructura de datos sin romper la encapsulación? Pues aquí te ofrecemos dos opciones: envía a tus clientes tu contenido (iterator) y que tu cliente diga que quiere hacer con cada uno de tus objetos (visitor)

Considera introducir un "mediador" en tus diseño si los mensajes entre los objetos convierte tu diagrama de clases en una maraña de relaciones.

El memento pattern nos ofrece una solución elegante al problema de guardar el estado de un objeto sin exponer detalles de su implementación.

Mis clases centrales, las más importantes de la aplicación, las debo modificar continuamente ya que el resto del sistema depende de sus acciones. ¿Te suena este problema? Aplica el observer pattern y será cosa del pasado.

Muchos objetos son representables mediante un diagrama de estados. Su comportamiento está muy influenciado según su estado actual. Pero en un lenguaje estáticamente tipado (como Java) un objeto no puede cambiar de tipo una vez creado. Con el state pattern podremos simular estos cambios de comportamiento de forma elegante.

Muy relacionado con el state pattern: no hemos de dejar que la naturaleza de lenguaje estáticamente tipado nos impida ver soluciones flexibles aplicando la "ilusión" de cambiar de implementación según nuestros intereses.

Una de las refactorizaciones más potentes y usadas es el "extract method". Con el template pattern vamos a multiplicar las situaciones donde podemos extraer un comportamiento común para evitar duplicidades en nuestro código.