DRY (Don’t Repeat Yourself o No te repitas)

Este será nuestro primer principio de diseño orientado a objetos, lo que podemos traducir como que no escribas código duplicado. Si os encontrais con que tenéis el mismo bloque de código en dos zonas distintas, deberíais considerar separalo en un método a parte. O quizás estais usando un valor fijo varias veces, lo mejor es usar una constante privada, o pública y estática, pero en ambos casos final.

Obviamente, el mayor beneficio de esto es el mantenimiento que ofrece. Aunque tampoco se debe abusar de esto. La duplicación no es por el código en sí, si no por la funcionalidad que ofrece. Vamos a ponernos en situación: estamos validando dos ids muy distintos usando un código muy parecido. La idea inicial es juntarlos en un mismo método y reutilizar. Pero no debe ser así. Vamos a pensar un poco…

Son dos validaciones distintas, y por tanto, el código ofrece dos funcionalidades distintas. ¿Qué pasaria si en un año el formato de uno de los ids cambia? Si nos hemos decantado por usado la misma función para validar ambos, al actualizar la función, uno de ellos dejará de funcionar. Esto se podría haber evitado.

El principio DRY se refiere a trozos de código que parece iguales y además hacen cosas iguales. Debe tenerse esto muy en cuenta.

Encapsular lo que puede cambiar

Lo único cierto que nos vamos a encontrar en el Software es que cambia. De modo que debemos encapsular lo que vemos, o sospechamos, que puede cambiar. Esto ofrece muchas ventajas, como por ejemplo pruebas y mantenimiento más sencillos. A la hora de programar en Java, lo mejor es hacer las variables y los métodos privados por defecto, y de ese modo aumentar el acceso paso a paso. Muchos patrones de diseño, como por ejemplo: Factory usa la encapsulación de este modo, dando flexibilidad de introducir nuevo código después sin impactar en el código existente.

El principio de diseño Cerrado-Abierto

Las clases, y los métodos o funciones, deberían estar abiertos para poder añadir nuevas funcionalidades, pero cerrados a las modificaciones. Esto nos permite no tener que modificar código que funciona y que ha sido probado. En una situación ideal, si debes añadir funcionalidad a una clase, tras terminar, únicamente deberías probar lo nuevo, y lo antiguo debería seguir funcionando de la misma forma que lo hacía antes. Esto se debe a que no deberías haber modificado nada de lo que había.

SRP (Single Responsibility Principle o Principio de responsabilidad única)

A la hora de modificar una clase, no debería existir más de una razón para llevarlo a cabo, o lo que es lo mismo, una clase únicamente debería dedicarse a una tarea bien concreta.

Si usas una clase para llevar a cabo más de una funcionalidad en Java, estarás introduciendo relaciones y/o uniones entre ambas. Lo peor de todo es que si aparece la necesidad de modificar una funcionalidad, lo más probable es que se rompa la otra. Esto requerirá reparar el problema, y luego una nueva tanda de pruebas para comprobar que todo está correcto. Podemos decir que se trata del doble de trabajo.

ISP (Interface Sgregation Principle o Principio de segregación de interfaces)

Este principio nos indica que una clase no debería implementar una interfaz si no la va usar. Esto ocurre sobre todo cuando una interfaz contiene más de una funcionalidad, y el cliente sólo necesita una de ellas.

El diseño de las interfaces puede ser complicado, dado que si creas una, ya no puedes modificarla sin romper todas las implementaciones realizadas. Pero uno de los beneficios de este principio de diseño es que, ya que Java obliga a implementar todos los métodos de la interfaz antes de usar una clase que la implemente, una sola funcionalidad significa menos métodos a implementar.

Programa usando interfaces y no implementaciones

Debes intentar siempre programa usando interfaces, esto te ayudará a obtener un código más flexible que podrá trabajar con cualquier nueva implementación de dichas interfaces.

De modo que sería razonable usar variables cuyo tipo sea una interfaz, y devolver en los métodos y usar en sus argumentos interfaces.

Principio de delegación

Intenta no hacer todo el trabajo por tu cuenta, delega cada tarea a la clase correspondiente. El ejemplo clásico usado del principio de delegación es la creación de los métodos equals() y hashCode(). A la hora de comparar dos objetos por igualdad siempre le preguntamos a la clase en sí que haga la comparación, en lugar de lo haga la clase padre (siempre que sea posible y correcto).

Todos estos principios de diseño pueden ayuda a conseguir un código mejor y más flexible, consiguiente una alta cohesión y baja relación entre las clases. La teoría es el primer paso, pero lo más importante es desarrollar estas habilidades para saberlas usar llegado el momento.

Debemos tener en cuenta que estos principios son realmente útiles para grandes proyectos y empresas que necesitan un mantenimiento muy largo. Nada es perfecto, de modo que tampoco intentes siempre resolver los problemas usando principio y patrones de diseño, simplemente son una buena práctica.

Espero comentarios.

Saludos,
Lázarus Surazal.