Si hablamos de diseño y desarrollo de #aplicaciones, Cuando mencionamos el principios #SOLID nos referimos a un acrónimo con 5 definiciones que nos ayudan a determinar los patrones de la #arquitectura y el #desarrollo de #software.
Los 5 principios SOLID
Los objetivos de estos 5 principios a la hora de escribir código son los de crear un software que cumpla con el objetivo por el cual fue creado y que sea robusto y estable. El código debe ser limpio y fácil de mantener. El código debe ser reutilizable y mantenible, de manera que puedan incorporarse cambios, nuevas funciones y mejoras de manera ágil. Los 5 principios son:
- S – Single Responsibility Principle (SRP)
- O – Open/Closed Principle (OCP)
- L – Liskov Substitution Principle (LSP)
- I – Interface Segregation Principle (ISP)
- D – Dependency Inversion Principle (DIP)
Principio de Responsabilidad Única
La primera letra del acrónimo. Es el principio más importante. La responsabilidad única refiere a la definición teórica que indica que “una clase debería tener una, y solo una, razón para cambiar”, es decir que cada clase que definamos debe tener una única responsabilidad. Si nos encontramos que para agregar una nueva funcionalidad debemos modificar más de una clase o que nuestro software tiene muchas relaciones entre sus clases, evidentemente no estamos cumpliendo este principio.
Principio Abierto/Cerrado
En este principio, se entiende que una entidad de software (clase, módulo, función, etc) deberían estar abiertas para poder extenderse (lo que significa que una entidad de software debe poder adaptarse a los cambios y nuevas necesidades) y cerradas para modificarse (significa que la adaptabilidad de la entidad se da como resultado de un diseño que facilite la extensión sin modificaciones, no por modificaciones realizadas en el core de dicha entidad)
Principio de Sustitución de Liskov
En el punto 3, se da nombre a este principio gracias a Barbara Liskov, la primera ingeniera en lograr el doctorado en Ciencias de la Computación. El principio de Liskov brinda pautas para trabajar con la herencia entre clases. La principal que debe cumplir si estamos realizando la herencia de una manera correcta es que cada clase que hereda de otra puede usarse como su padre sin necesidad de conocer las diferencias entre ellas. Los objetos deben poder ser reemplazados por instancias de sus subtipos sin alterar el correcto funcionamiento del sistema.
Principio de Segregación de la Interfaz
En este método se hace hincapié, en hacer interfaces específicas, es decir, tener interfaces con pocos métodos para finalidades concretas. Las interfaces nos dan una capa de abstracción que nos ayudan a desacoplar módulos; por lo tanto la interfaz es lo que nos da el comportamiento que nuestro código espera para comunicarse con otros módulos a través de métodos y propiedades.
Principio de inversión de dependencias
Último de los principios de SOLID. En este último punto, se especifica cómo deben ser las relaciones entre componentes para evitar el acoplamiento entre los módulos de un software, lo que busca reducir las dependencias entre los módulos del código para lograr un bajo acoplamiento de las clases.
Conclusión
SOLID tiene muchos detractores que suelen indicar entre sus criticas que solo toma algunos principios muy generales para un buen diseño de software de programación orientada a objetos y luego les coloca etiquetas.
Los principios SOLID son una guía de buenas prácticas, que están relacionados entre sí de forma muy estrecha y que al aplicarlos en nuestros desarrollos facilitan la creación de un código limpio, con menor acoplamiento, más flexible, más estable y más fácil de mantener.
[popup_anything id=”2076″]