Las 4 Reglas del Diseño Simple de Ken Beck son fundamentales para crear un software bien diseñado, facilitando la emergencia de diseños de calidad.
Las 4 Reglas que describe Ken Beck son:
Ejecutar Todos Los Test
No Contener Duplicados
Expresar la Intención del Programador
Minimizar el Número de Clases y Métodos
Ejecutar todas las Pruebas
Un diseño debe generar un sistema que actúe de la forma prevista.
Un sistema puede tener un diseño perfecto sobre el papel, pero si no existe una forma sencilla de comprobar si realmente funciona de la forma esperada, no debería implementarse.
Los sistemas que no se pueden probar, no se pueden verificar, y un sistema que no se puede verificar, no debe implementarse.
Crear sistemas testeables nos da las siguientes ventajas:
- Hace que diseñemos clases de tamaño reducido.
- Crearemos clases que cumplan el principio de SRP (Single Responsability Principle)
- Crearemos clases que cumplan el principio de DIP (dependency inversion principle).
- Obligamos a que nuestro sistema que tengan baja conexión y elevada cohesión entre objectos.
Todas estas ventajas nos ayudan a crear mejores diseños en nuestro sistema.
No Contener Duplicados
Una vez creada las pruebas, debemos mantener limpio el código y las clases.
Para ello refactorizamos el código progresivamente.
La presencia de las pruebas hace que perdamos el miedo a limpiar el código y que este resulte dañado.
En la refactorizacion podremos:
- Aumentar la cohesión
- Reducir las conexiones
- Separar las preocupaciones
- Modularizar aspectos del sistema
- Reducir el tamaño de funciones y clases
- Elegir nombre adecuados
- Garantizar la capacidad de expresión
- Minimizar el numero de clases y métodos
- Eliminar duplicados
Los duplicados son los mayores enemigos de un sistema bien diseñado.
Expresar la Intención del Programador
El principal coste de un proyecto de software es su mantenimiento a largo plazo. Un sistema complejo necesita mas tiempo para entenderlo y aumenta las posibilidades de de errores.
Para minimizarlo, el código debe expresar con claridad la intensión de su autor. Cuanto mas claro sea el código, menos tiempo perderán otros en intentar comprendedlo.
Se puede ganar expresividad si:
- Se eligen nombres adecuados. Al ver el nombre de una clase o función, no nos deben sorprender sus responsabilidades.
- Se reduce el tamaño de las funciones y clases, ya que resultara mas sencillo asignarle nombres, crearlas y comprendedlas.
- Se crean test unitarios. Uno de los principales objetivos de los test es servir de documentación mediante ejemplos. Los que lean las pruebas deben entender con facilidad como funciona una clase.
- Le dedicamos tiempo al terminarlo. Muchas veces conseguimos que nuestro código funcione y seguimos al siguiente problema,sin detenernos en facilitar la lectura del código a otros. Debemos dedicar tiempo para intentar mejorar la expresividad de nuestro código.
Minimizar el Número de Clases y Métodos
Nuestro objetivo es reducir el tamaño general del sistema además del tamaño de las clases y funciones.
Pero la regla de minimizar el numero de clases y funciones es la de menor prioridad de las cuatro.
Por ello, aunque sea importante reducir la cantidad, es más importante contar con pruebas, eliminar duplicados y expresarse correctamente.