Principios de diseño

Un principio de diseño es una técnica que puede ser aplicada al diseño o escritura de código con el objetivo de crear código más flexible, escalable y fácil de mantener.

-Head First Object Oriented Analysis and Design-

Después de haber hecho nuestro análisis, haber obtenido requerimientos, hacer nuestros casos de usuario, diagramas y demás tareas, llega el momento de escribir el preciado código. Lo correcto sería que llegado este punto, estemos más que preparados, pero la realidad es que ¡nunca lo estaremos! Para ese último escalón antes del código perfecto es que existen los principios de diseño.

Principio #1: Principio Open-Closed (OCP por sus siglas en inglés)

Las clases deben ser abiertas a la extensión, escalabilidad, pero cerradas a la modificación.

¿Cómo es una clase perfecta? Es una clase que cualquiera pueda utilizar siempre que lo necesite. Si estas clases cumplen su función a la perfección, entonces al tomar la clase en otro proyecto, debería poder utilizarla sin problemas. Además, debería ser innecesario cambiar cualquier parte del código para hacerla funcionar. Esto significa que está cerrada a la modificación. Sin embargo, hay una infinidad de posibilidades para nuestras clases, por lo que cualquiera debería poder agregar funcionalidad adicional fácilmente, lo que significa que nuestra clase estaría abierta a la extensión.

Principio #2: Principio No te repitas a ti mismo (DRY, por sus siglas en inglés)

Evita el código duplicado abstrayendo las cosas comunes y colocándolas en un solo sitio.

Si tenemos varias clases que van a hacer una misma cosa, ¿por que no unirlas en una sola? El código duplicado puede significar trabajo adicional que es totalmente innecesario. Este es uno de los principios del paradigma orientado a objetos y nos resulta muy útil cuando trabajamos con programas más complejos.

En el caso que tengamos código repetido que por alguna razón no teníamos previsto, la solución es sencilla:

1. Crea una nueva función con el nombre de lo que hace tu código repetido.
2. Corta tu código repetido y pégalo en la nueva función.
3. En el espacio donde antes estaba tu código, llama a la nueva función.

Principio #3: Principio de la responsabilidad única (SRP, por sus siglas en inglés)

Todo objeto en el sistema debe cumplir con una única responsabilidad. Todo lo demás que pueda contener el objeto debe ser acorde a esta responsabilidad.

Suena un poco extraño que una clase cumpla una sola responsabilidad. Sin embargo, esto tiene todo el sentido del mundo al momento de analizarlo en la práctica. Supongamos que trabajamos en un juego de ajedrez. ¿Cuál sería la responsabilidad del tablero? Toma un segundo para pensarlo y continúa leyendo. Su responsabilidad no es otra que contener las piezas. El movimiento es una clase aparte. Las piezas son una clase aparte. Y siendo más específicos ¿de quién es la responsabilidad de saber donde se colocarán las piezas al inicio del juego? Bueno, esto podría implementarse de dos maneras que podrían considerarse correctas:

• El tablero default debería conocer la posición original de las piezas.
• Las piezas deberían, de acuerdo al tipo de tablero, seleccionar su posición inicial.

Si lo pensamos dos veces, lo correcto sería tomar la segunda opción. ¿Por qué? Bueno, podemos pasar a reutilizar los métodos para mover las piezas y con eso posicionarlas. De esta forma las piezas tienen la responsabilidad de colocarse o moverse en el tablero y evitamos el código duplicado.

Principio #4: Principio de sustitución de Liskov (LSP, por sus siglas en inglés)

Una subclase debe ser sustituible por su clase principal.

La herencia es fundamental en el paradigma orientado a objetos, por lo que es imprescindible tener un principio que nos ayude a mantener el orden. ¿Cómo nos ayuda esto a mantener el orden? Es sencillo. Si una subclase no puede sustituirse por la súper clase, quizá no se esta aplicando correctamente la herencia.

Figura fig = new Cuadrado()

Esta pequeña linea podría ser el caos total. El problema es que si cuadrado no esta correctamente implementado, entonces podríamos decir, de manera teórica, que cuadrado no es una figura, por lo que no pueden sustituirse.

Cumplir con este principio nos ayudará a evitar problemas futuros relacionados con la herencia y a hacer nuestro código mucho (mucho) más entendible.

Seguir estos principios convergerá a un código ordenado, limpio, reutilizable y escalable. Es una buena práctica revisar nuestro código al finalizar y verificar que se cumpla con estos principios. Si lo hacemos correctamente, podremos evitarnos bastante retrabajo en el futuro y tener un futuro feliz como programadores cool.