Principios de diseño

Las técnicas se convierten en principios si están ampliamente aceptadas, se practican y se demuestra su utilidad en cualquier sector. Estos principios se convierten en soluciones para que los diseños de software sean más comprensibles, flexibles y mantenibles. En esta sección trataremos los principios de diseño SOLID, KISS y DRY.

SOLID

Los principios SOLID son un subconjunto de muchos principios promovidos por el ingeniero de software e instructor estadounidense Robert C. Martin. Estos principios se han convertido en principios estándar de facto en el mundo de la programación orientada a objetos y han pasado a formar parte de la filosofía central de otras metodologías y paradigmas.

SOLID es un acrónimo de los cinco principios siguientes:

• Single responsibility principle - SRP (Principio de responsabilidad única): Una entidad o módulo de software sólo debe tener una única responsabilidad. Debe evitar conceder a una entidad múltiples responsabilidades:

• Open-closed principle - OCP (Principio de apertura y cierre): Las entidades deben diseñarse de forma que estén abiertas a la ampliación pero cerradas a la modificación. Esto significa que se pueden evitar las pruebas de regresión de los comportamientos existentes; solo hay que probar las extensiones:

• Liskov substitution principle - LSP (Principio de sustitución de Liskov): Las instancias de las clases padre o base deben poder ser sustituidas por instancias de sus clases derivadas o subtipos sin alterar la cordura del programa:

• Interface segregation principle - ISP (Principio de segregación de interfaces): En lugar de una gran interfaz común, hay que planificar múltiples interfaces específicas para cada escenario para mejorar el desacoplamiento y la gestión de los cambios:

• Dependency inversion principle - DIP (Principio de inversión de la dependencia): Hay que evitar cualquier dependencia directa de implementaciones concretas. Los módulos de alto nivel y los de bajo nivel no deberían depender unos de otros directamente, y en su lugar, ambos deberían depender de las abstracciones en la medida de lo posible. Las abstracciones no deben depender de los detalles y los detalles deben depender de las abstracciones.

Don’t repeat yourself (DRY)

Con DRY, un sistema debe ser diseñado de tal manera que la implementación de una característica o un patrón no debe repetirse en múltiples lugares. Esto supondría una sobrecarga de mantenimiento, ya que un cambio en los requisitos haría necesaria una modificación en múltiples lugares. Si no se realiza una actualización necesaria en un lugar por error, el comportamiento del sistema será incoherente. En lugar de ello, la característica debe estar envuelta en un paquete y debe ser reutilizada en todos los lugares. En el caso de una base de datos, hay que considerar el uso de la normalización de datos para reducir la redundancia:

Esta estrategia ayuda a reducir la redundancia y a promover la reutilización. Este principio también ayuda a la cultura de una organización, fomentando una mayor colaboración.

Keep it simple, stupid (KISS)

Con KISS, un sistema debe diseñarse de la forma más sencilla posible, evitando diseños complicados, algoritmos, nuevas tecnologías no probadas, etc. Hay que centrarse en aprovechar los conceptos correctos de POO y reutilizar patrones y principios probados. Incluya cosas nuevas o no simples sólo si es necesario y añade valor a la implementación.

Si lo haces de forma sencilla, podrás hacer mejor lo siguiente:

• Evitar errores en el diseño/desarrollo

• Mantener el tren en marcha (siempre hay un equipo cuyo trabajo es mantener el sistema, aunque no sea el equipo que lo desarrolló en primer lugar)

• Lea y comprenda su sistema y su código (su sistema y su código tienen que ser comprensibles para las personas que son nuevas en él o para las que lo utilicen en un futuro lejano)

• Hacer una gestión de cambios mejor y menos propensa a errores