Patrón de diseño Adapter

Adapter es un patrón de diseño estructural. Este es el único patrón que tiene los dos ámbitos, clases y objetos, ya que podemos implementarlos de dos formas diferentes. Este patrón se utiliza cuando tenemos dos elementos de una aplicación los cuales necesitamos que trabajen juntos, pero sus interfaces de comunicación no son compatibles. Para esos casos creamos una clase intermedia que facilita la comunicación entre ambas. Así, Adapter servirá como puente entre ambos elementos.

Algunas personas describen a este patrón con la frase: "Obtener la interface que quieres a partir de la interface que tienes" o "proporcionarle al cliente un objeto con la interface que necesita".

En este tutorial se mostraré la funcionalidad de este patrón, junto con dos estrategias diferentes de implementación, una para el ámbito de clases y otro para el ámbito de objetos.

Patrón de Diseño Strategy

Strategy es un patrón de diseño de comportamiento con el ámbito de objeto. Su finalidad es la de poder cambiar el algoritmo o comportamiento de un objeto en tiempo de ejecución. Esto ayuda cuando tenemos una aplicación en la que varían solo ciertas partes de la lógica. Con este patrón podemos aislar estos comportamiento o algoritmos en clases diferentes y elegir entre uno u otro en tiempo de ejecución.

En este tutorial te explicó más a fondo cómo funciona este patrón y te muestro una estrategia de implementación del mismo.

Patrón de Diseño Template Method

Template Method es un patrón de diseño de comportamiento del ámbito de clases. Con este patrón se define el esqueleto de un algoritmo en una clase abstracta, y se deja que sean las subclases quienes proporcionen los detalles concretos de algunos o todos los pasos de ese algoritmo. Lo interesante de este patrón es que también da la opción a las subclases de redefinir los pasos de acuerdo con sus necesidades, sin cambiar la estructura del algoritmo.

En este tutorial te explico los detalles de Template Method, y te muestro una estrategia de implementación.

Diferencias: Simple Factory vs. Factory Method vs. Abstrac Factory

En los tutoriales anteriores vimos tres patrones de diseño que son muy parecidos en nombre y concepto: Simple Factory (conocida también como Factory, a secas), Factory Method y Abstract Factory. La finalidad de los tres patrones es la misma: encapsular la instanciación de objetos. Sin embargo, cada uno de los patrones lo hace de una forma diferente dependiendo del problema que estemos tratando de resolver.

Al tener nombres tan parecidos, estos tres patrones generan mucha confusión entre los desarrolladores.

En este tutorial te explico las diferencias entre estos tres patrones y te doy algunas recomendaciones de cuándo debes usar uno u otro.

Patrón de Diseño Abstract Factory

Abstract Factory es un patrón de diseño creacional del ámbito de objetos. Este patrón ayuda a crear grupos o familias de objetos que, aunque en esencia son diferentes, tienen una relación de herencia o dependencia entre ellos a niveles de padres e hijos, pero también a nivel de hermanos. De esta forma ayudan a que la construcción de esa familia de objetos mantenga una lógica y coherencia, manteniendo al mismo tiempo un alto nivel de abstracción y bajo acoplamiento a través del polimorfismo.

En algunas ocasiones este patrón es descrito como una fábrica de fábricas lo cual, en parte, tiene razón, pero esta descripción se queda corta con respecto al potencial que ofrece.

En este tutorial te explicaré más en detalle en qué consiste este patrón de diseño, así como una estrategia de implementación.

Patrón de diseño Factory Method

El patrón de diseño Factory Method es un patrón de diseño creacional del ámbito de los objetos; es el único patrón de este tipo de los 24 definidos originalmente por la GoF.

Este patrón se usa mucho dentro del JDK y en frameworks como Spring, además de en un sin número de librerias y especificaciones, ya que uno de sus principales objetivos es poder ocultar los detalles de la implementación a través de una clase abstracta o interface para definir y mantener relaciones entre objetos.

En este tutorial veremos varias estrategias de implementación y una variación a las cual se les conoce simplemente como Factory o como Simple Factory y sus diferencias con Factory Method.

Recomendaciones de qué debe incluir un buen mensaje de commit al repositorio de código

Hoy en día, al escribir una aplicación, ya sea solo o en equipo, lo más normal es que subamos nuestro código a un repositorio (publico o privado).

 

Git es actualmente la opción más popular, y algunos sitios como GitHub y GitLab ofrecen espacio gratuito de almacenamiento (con ciertas restricciones y condiciones, pero gratuito).

 

 Al momento de inicializar un repositorio, o hacer alguna modificación, hay un paso importante y al que normalmente no le prestamos mucha atención: Escribir un mensaje de las modificaciones que hemos hecho a la aplicación y que van incluidas en ese commit particular. Algunas veces lo dejamos de lado (escribimos cualquier cosa), porque pensamos que es un mensaje que no volveremos a leer nunca más. Sin embargo, cuando ocurre un problema o queremos saber por qué se hizo una modificación en particular, el escribir un buen mensaje puede ser la diferencia entre pasar horas revisando el código antes y después del commit, o el pasar solo unos segundos leyendo el mensaje para entender qué fue lo que ocurrió.

En este artículo te daré algunas recomendaciones de qué debe incluir y cómo estructurar ese mensaje para que, además de ser útil, no pases una vida pensando en qué escribir.

Introducción a los patrones de diseño

Con este artículo comienza una nueva serie, que será el inicio de varias otras nuevas series, las cuales hablarán de diversas formas de mejorar la calidad de nuestro código, con el objetivo de hacerlo más mantenible, flexible, entendible, y mejor estructurado.

Con estas series busco brindarte una base formal que te ayude a afrontar problemas complejos y te prepare mejor para desarrollar tu carrera profesional.

En esa serie te explicaré qué son los patrones de diseño y hablaré de los patrones de diseño más comunes, y te mostraré diversas formas o estratégias para implementar cada uno de ellos.

En este primer artículo explicaré rápidamente qué son los patrones de diseño, cómo se clasifican, junto con una lista que se irá actualizando conforme vaya agregando más artículos.

Sin más, vamos al tema.

Spring Boot Parte 2 - Externalizando la Configuración de la Aplicación

Algo muy importante y fácil de olvidar cuando creamos una aplicación, es que (si todo sale bien), esta vera la luz en un mundo productivo y será ahí cuando comenzará su vida útil, en un mundo fuera de la computadora del desarrollador.

Antes de llegar a su destino final (el ambiente de producción) una aplicación sana debería pasar por al menos dos ambientes. El primero es el ambiente del desarrollador, la computadora o computadoras en las que nunca nada falla ni sale mal :). El segundo ambiente debería ser el ambiente de integración continua; aquí será una computadora configurada en la que la aplicación se compilará y se ejecutarán una serie de pruebas automáticas que van desde las pruebas funcionales, hasta pruebas de carga y estrés. El tercer ambiente es un ambiente de testing, aquí un profesional altamente capacitado (el tester) hará su mayor esfuerzo por hacer que nuestra aplicación falle o "se rompa" en formas que nunca imaginamos al momento de escribir nuestro código productivo o de pruebas unitarias.

Una vez que nuestra aplicación sobrevive en los ambientes anteriores, llegará finalmente al ambiente productivo. En este ambiente es donde pasará su vida útil sirviendo a usuarios que no estuvieron involucrados dentro del proceso de construcción.
Como podemos ver, nuestra aplicación pasara a través de varios ambientes, algunos de los cuales no tendremos control y serán distintos al ambiente creado dentro de las máquinas de desarrollo. Debido a esto es muy importante tener un mecanismo que nos permita externalizar la configuración de nuestras aplicaciones Spring Boot y que se ejecute de la misma forma sin importar el ambiente en el que se encuentre. Algunos elementos que comúnmente cambian dependiendo del ambiente en el que ejecutemos la aplicación son: rutas, usuarios de conexiones a base de datos, puertos de funcionamiento, nombres de servidores, etc.

En este tutorial aprenderemos las formas que Spring Boot proporciona para colocar esta información de configuración fuera del código fuente de la aplicación (evitando con esto que tengamos que recompilarla cada vez que vayamos a moverla de ambiente), y las prioridades o precedencias que Spring Boot asigna a cada una de estas formas.

Lombok, escribiendo menos código y logrando más cosas

En este tutorial no veremos un Framework, sino una herramienta Java que nos ayudará a simplificar mucho el código que escribimos en cada una de nuestras clases de datos; o sea, las clases que no contienen lógica de negocio, sino que nos ayudan a "transportar" información, como son los POJOs o los Value Objects.

Lombok es una librería Java que automáticamente se conecta a nuestro editor o herramienta de construcción (como pueden ser Maven o Eclipse) y que nos ayuda a generar código para las tareas más repetitivas de nuestras clases como son la generación de métodos setter y getter, constructores, toString, equals, etc. ¿Recuerdan en los tutoriales de Hibernate como la parte más tardada era generar las entidades por la cantidad de métodos getter y setter que estas tenían? Esas clases ocupan mucho espacio, en término de líneas de código; todo ese código podremos ahorrárnoslo con Lombok, ya que por medio de anotaciones le indicaremos qué es lo que queremos que genere.

En este tutorial aprenderemos cómo instalar Lombok en nuestro IDE y veremos algunos ejemplos de uso.