Algunos de estos Principios de Diseño son:
- Encapsular lo que varía --> Considerado como los principios fundacionales del diseño, este principio se encuentra en funcionamiento en casi todos los patrones de diseño. Este principio sugiere, identificar los aspectos de sus aplicaciones que varían y separarlos de lo que permanece igual. Si un componente o módulo de tu aplicación está destinado a cambiar con frecuencia, entonces es una buena práctica separar esta parte del código de los estables para que después podamos ampliar o alterar la parte que varía sin afectar a los que no varían. La mayoría de los patrones de diseño como Strategy, Adapter, Facade, Decorator, Observer, etc siguen este principio.
- Favorecer la composición sobre la herencia-->La programación orientada a objetos proporciona 2 tipos de relaciones entre las clases y sus instancias: has-a (composición) e is-a (herencia). Este principio de diseño nos sugiere esencialmente que "la relación has-a debe ser preferida sobre la relación is-a.". A veces la herencia cuando se usa en exceso hace que nuestro código sea más rígido y no extensible.
- Programa a interfaces-->Este principio de diseño nos guía para hacer uso de los tipos abstractos y no de los concretos. "Programar para interfaces" significa en realidad programar para un supertipo como una interfaz o una clase abstracta en java.
- Acoplamiento flexible-->Es un principio que sugiere que "los componentes que interactúan entre sí deben ser independientes unos de otros, confiando lo menos posible en el conocimiento de otro componente". Este es un principio que seguimos en una arquitectura de microservicios. Los servicios que interactúan entre sí son independientes unos de otros. La interacción se basa estrictamente en los contratos de datos. La implementación del acoplamiento flexible variará de un escenario a otro en función del problema que tratemos de resolver.
- Principios SÓLIDOS-->Es un conjunto de 5 principios que forman el acrónimo:
- Principio de responsabilidad única (Single responsibility principle): Una clase debe tener una sola razón para cambiar. Este principio sugiere que las responsabilidades de una clase deben ser limitadas. No es una directriz clara porque no tenemos una instrucción específica en la que basarnos para juzgar esto. Sin embargo, la idea básica cuando se diseña usando este principio debería ser comprobar si los métodos dentro de una clase están cohesionados, es decir, ¿realmente necesitan estar juntos?
- Principio de apertura y cierre (Open closed principle): Este principio establece que nuestro diseño debe estar abierto a la ampliación pero cerrado a las modificaciones. ¿Pero qué pasa si queremos añadir una nueva implementación en nuestro diseño? Podemos abordar esto de dos maneras:
- Extendemos la funcionalidad existente a una nueva clase y añadimos las implementaciones allí
- Utilizar la composición para aceptar nuevos comportamientos
- Principio de sustitución de Liskov (Liskov’s substitution principle):A veces la herencia puede romper el sistema cuando sustituimos nuestra clase derivada por la clase padre. El principio de Liskov sugiere esencialmente que: "Siempre deberías poder sustituir los subtipos por su clase base".
- Principio de segregación de la interfaz (Interface segregation principle): Este principio sugiere que una "interfaz debe estar siempre cohesionada". Es decir, los componentes de la interfaz deben estar muy relacionados entre sí. Cualquier componente que no esté relacionado entre sí debe ser separado y segregado.
- Principio de inversión de la dependencia (Dependency inversion principle): El principio de inversión de la dependencia se utiliza para desacoplar los módulos de software. Establece que "los módulos de alto nivel no deben depender de los de bajo nivel. En cambio, ambos deben depender de la abstracción".
Los principios de diseño que se han tratado en este artículo son los más fundamentales. Hay algunos principios más como
- DRY significa "Don't Repeat Yourself" (no te repitas), que establece que "cada pieza de conocimiento debe tener una representación única, inequívoca y autorizada dentro de un sistema". En otras palabras, significa que cada módulo debe ser único en sí mismo.
- AHA significa Avoid Hasty Abstractions, que básicamente nos sugiere que a veces las abstracciones pueden llevar a una base de código rígida. Y cuando lo hacen, es mejor evitarlas.
- KISS son las siglas de Keep It Simple Stupid (Manténgalo Simple y Estúpido), que sugiere que nuestra implementación debe ser lo más simple posible. Cualquier cosa que introduzca complicaciones en la implementación debe ser desacoplada utilizando cualquiera de los principios anteriores.
