Principios SOLID
El acrónimo SOLID, hace referencia a un conjunto de principios en el desarrollo de software que nos indican cómo organizar funciones y datos estructurados en clases, y cómo deben estos interconectarse. Estos cinco principios, buscan que el código sea más entendible, flexible y mantenible.
Estos principios fueron creados por Robert C. Martin en un paper del año 2000 llamado Design Principles and Design Patterns y hacen parte de un grupo más grande de principios y buenas prácticas promovidos por él. Cada letra del acrónimo hace referencia a un principio diferente.
El objetivo de estos principios radica en la creación de estructuras de sofware de nivel intermedio (nivel de módulo) que tengan las siguientes características:
- Adaptabilidad al cambio
- Claridad y facilidad de entendimiento
- Servir como base para componentes adicionales
Single Responsability principle
El principio de responsabilidad única hace rereferencia a que una clase solo debe tener un trabajo o responsabilidad. Esto visto de otra forma, significa que solo debe existir una razón para que una clase cambie. Las clases con muchas responsabilidades son difíciles de mantener.
Principio de Responsabilidad Única en diseño orientado a objetos (SOLID)
Open Close principle
Este principio dice que las entidades (clases, métodos o funciones) deben estar abiertas para extensión pero cerradas para modificación. Que una entidad sea abierta para extensión, significa que es posible cambiar el comportamiento de dicha entidad. Por otro lado, que sea cerrada para modificación, implica que debe ser posible cambiar el comportamiento sin modificar el código fuente original.
Principio Open-Closed en diseño orientado a objetos (SOLID)
Liskov Substitution principle
Este principio dice que los objetos de un programa pueden ser reemplazados por sus subtipos sin alterar el correcto funcionamiento del programa. Es decir, un argumento de una función o método que acepte una clase o interfaz, debería funcionar igual con cualquier subtipo de la misma clase o interfaz. Para que esto sea posible, es necesario que la signature de los métodos implementados o sobreescritos sean iguales y no agreguen o cambien el TIPO del resultado de la función (incluyendo excepciones).
Principio de Sustitución de Liskov en diseño orientado a objetos (SOLID)
Interface Segregation principle
Este principio dice que un cliente no debe forzar la implementación de una interfaz que no utiliza. Dicho de otra forma, muchas interfaces cliente específicas son mejores que una interfaz de propósito general. Si una método o función recibe una dependencia que implementa otros métodos que no son de su interés, debe realizarse una segregación y crear una interfaz específica.
Principio de Segregación de Interfaces en diseño orientado a objetos (SOLID)
Dependency Inversion principle
Este principio dice que las dependencias deben estar dadas por abstracciones y no por clases concretas. Es uno de los principios tal vez más difíciles de entender y hace referencia a desacoplar el código. Las funciones o métodos no deberían depender de clases concretas, ya que esto genera un acomplamiento con el código de bajo nivel implementado en dicha clase; en su lugar, las dependencias deben darse a alto nivel, es decir, con clases abstractas o interfaces.
Principio de Inversión de Dependencias en diseño orientado a objetos (SOLID)