Los principios SOLID tienen relación con los patrones de diseño, conocidos en inglés como SOLID principles, son 5 reglas fundamentales de la programación orientada a objetos, recopiladas por Robert C. Martin en su libro “Agile Software Development: Principles, Patterns and Practices”.
Su objetivo es que nuestro software sea más limpio, flexible, escalable y mantenible. Siguiendo estas pautas tendremos un código de mejor calidad. Esto es aplicable a cualquier lenguaje de programación orientado a objetos.
Estos 5 principios se reúnen en el acrónimo SOLID, donde cada letra es un concepto que veremos a continuación:
- S: Single Responsibility Principle (SRP) / principio de responsabilidad única.
- O: Open/Closed Principle (OCP) / principio abierto/cerrado.
- L: Liskov Substitution Principle / principio de substitución de Liskov.
- I: Interface Segregation Principle / principio de segregación de interfaces
- D: Dependency Inversion Principle / principio de inversión de dependencias
1. Principio de Responsabilidad única
El principio de responsabilidad única se basa en que un objeto debería tener una única responsabilidad. Según Robert C. Martin, un objeto sólo debería tener una única razón para cambiar.
Si un módulo o una clase agrupa funcionalidad muy diversa, como por ejemplo la típica clase de utilidades en la que podemos encontrar de todo un poco, decimos que su cohesión es baja. Por el contrario, tiene una única responsabilidad, su cohesión es alta.
Una alta cohesión es lo ideal para mejorar nuestro código en cuanto a mantenibilidad y reusabilidad.
2. Principio de Abierto/Cerrado
El principio de Abierto/Cerrado establece que un objeto debe estar abierto para extender su funcionalidad, pero cerrado para modificarla.
Esto parece difícil de entender pero es esencial para asegurar que cuando queramos añadir otra funcionalidad a nuestro código, no se “rompa” la que ya teníamos funcionando. Para ello recurrimos a la herencia y a las interfaces que nos facilita la programación orientada a objetos.
3. Principio de Sustitución de Liskov
Debemos el nombre de este principio a Bárbara Liskov y quien introdujo la idea de que cada clase que hereda de otra puede usarse como su padre sin necesidad de conocer las diferencias entre ellas.
Su objetivo es asegurar que una subclase pueda ser sustituida por su superclase sin que aparezcan errores en el código.
Cumpliendo con este principio confirmamos que nuestro programa tiene una jerarquía de clases fácil de entender y un código reutilizable.
Sus tres claves fundamentales son las siguientes:
- Las precondiciones no pueden ser reforzadas por una clase hija y las postcondiciones no pueden ser debilitadas por un clase hija.
- Las invariantes establecidas por la clase padre deben ser mantenidas por las clases hijas.
- Las restricciones históricas dicen que no puede existir un método en la clase hija que vaya en contra de un comportamiento de su clase padre.
4. Principio de Segregación de Interfaces
El principio de Segregación de Interfaces, fue concebido con la finalidad de mantener un sistema desacoplado de los demás sistemas de los cuales depende.
Establece que los objetos no deberían verse forzados a depender de interfaces que no utilizan.
Un cliente solo debe conocer los métodos que van a utilizar y no aquellos que no utilizarán. Cada clase implementará las interfaces que necesite y use, ninguna más.
Para ello debemos evitar interfaces grandes, para no tener implementaciones que no sean necesarias.
5. Principio de Inversión de Dependencias
Establece que las dependencias deben estar en las abstracciones, no en las concreciones.
- Los módulos de alto nivel no deberían depender de los módulos de bajo nivel. Ambos deberían depender de abstracciones (p.ej., interfaces).
- Las abstracciones no deberían depender de los detalles. Los detalles (implementaciones concretas) deben depender de abstracciones.