Principios SOLID

Author
Por Darío Rivera
Publicado el en 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.

El uso de la palabra clase no implica que estos principios son solo aplicables a la programación orientada a objetos. Una clase, puede interpretarse como un agrupamiento de datos y funciones, independientemente si se le denomina específicamente clase o no.

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)


Acerca de Darío Rivera

Author

Application Architect at Elentra Corp . Quality developer and passionate learner with 10+ years of experience in web technologies. Creator of EasyHttp , an standard way to consume HTTP Clients.

LinkedIn Twitter Instagram

Sólo aquellos que han alcanzado el éxito saben que siempre estuvo a un paso del momento en que pensaron renunciar.