Cuando escribimos código debemos cumplir unos requisitos básicos que nos aseguren que nuestro software es de calidad. El código debe ser robusto, estable, limpio y escalable. Así conseguiremos que nuestro software funcione de manera rápida y fiable, y podremos modificarlo o ampliarlo fácilmente.
Para conseguir un código que cumpla con estos requisitos Robert C. Martin (también conocido como el tío Bob) escribió los cinco principios del diseño orientado a objetos, cuyo acrónimo es SOLID:
- S – Single Responsibility Principle
- O – Open Closed Principle
- L – Liskov Substitution Principle
- I – Interface Segregation Principle
- D – Dependency Inversion Principle
Veamos qué es lo que dice cada principio:
Single Responsibility Principle (Principio de Responsabilidad Única)
“A class should have one and only one reason to change, meaning that a class should have only one job.”
El primer principio nos dice que “una clase debería tener una y solo una razón para cambiar, significando esto que una clase tiene que tener una sola función”.
Robert explica cómo hacerlo: “Gather together the things that change for the same reasons. Separate those things that change for different reasons”, es decir: “Reúne las cosas que cambian por las mismas razones. Separa aquellas que cambian por razones diferentes”.
Open/Closed Principle (Principio de Abierto/Cerrado)
“Objects or entities should be open for extension but closed for modification.”
El segundo principio de SOLID dice “Objetos o entidades deberían estar abiertas a extensiones pero cerradas a modificaciones”. Esto significa que deberíamos ser capaces de extender el comportamiento de una clase sin modificarla.
Liskov Substitution Principle (Principio de Sustitución de Liskov)
“Let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.”
En español este principio nos dice “Sea q(x) una propiedad demostrable de los objetos x de tipo T. Entonces q(y) debería ser demostrable para objetos y de tipo S donde S es un subtipo de T”. Esto quiere decir que las clases derivadas deben poder sustituirse por sus clases base sin alterar el correcto funcionamiento del sistema.
Incumplir este principio implica también violar el principio de Abierto/Cerrado.
Interface Segregation Principle (Principio de Segregación de la Interfaz)
“A client should never be forced to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use.”
El siguiente principio de SOLID dice “Nunca se debería obligar a un cliente a implementar una interfaz que no utilice, o no se debería obligar a los clientes a depender de métodos que no utilicen”. Las interfaces deben ser específicas para un tipo de cliente y deben tener una finalidad concreta.
Según el Interface Segregation Principle es mejor tener muchas interfaces que definan pocos métodos que tener una interface forzada a implementar muchos métodos que no se usarán.
Dependency Inversion Principle (Principio de Inversión de Dependencias)
“Entities must depend on abstractions, not on concretions. It states that the high-level module must not depend on the low-level module, but they should depend on abstractions.”
Por último, el Principio de Inversión de Dependencias dice “Las entidades deben depender de abstracciones, no de concreciones. Establece que el módulo de alto nivel no debe depender del módulo de bajo nivel, sino que debe depender de abstracciones.”
Con este principio lo que Robert nos aconseja es reducir las dependencias entre los módulos del código y con ello conseguir que las clases no se acoplen.
Conclusión
Seguir los principios SOLID es una buena práctica, pero no imprescindible. Los 5 principios nos ayudan a conseguir un código más limpio, mantenible y escalable, pero no son leyes absolutas. Robert C. Martin nos dice en el artículo Getting a SOLID start que «Seguir las instrucciones en la lata de pintura no te enseñará a pintar». Aplicar estos principios sin entenderlos o sin juicio própio no convertirá a nadie en un buen programador. Sin embargo es buena idea conocerlos, tanto para nuevos programadores como para programadores con más experiéncia, y ponerlos en práctica siempre que se pueda.
Si te ha quedado alguna duda sobre los principios SOLID o si quieres hacernos cualquier otra consulta contacta con nosotros.
