Tiempo de lectura · 2 minutos

Preliminares

Mucho hemos oído hablar de SOLID, y como su puesta en práctica en nuestros desarrollos nos ayudan a construir software de mayor calidad, que todo el mundo lo entienda, mantenible, flexible, ser probado con mayor facilidad,  mejorando la cohesión y disminuir el acoplamiento entre sus componentes y  orientado al cambio.

SOLID es un acrónimo de los primeros cinco principios de diseño orientado a objetos (OOD) de Robert C. Martin (también conocido como el tío Bob).

Nota: Si bien estos principios se pueden aplicar a varios lenguajes de programación, el código de muestra contenido en este artículo CSharp 10.

Estos principios establecen prácticas que se prestan al desarrollo de software con consideraciones de mantenimiento y ampliación a medida que crece el proyecto. La adopción de estas prácticas también puede contribuir a evitar olores de código, refactorización de código y desarrollo de software ágil o adaptativo.

SÓLID significa:

S - Principio de responsabilidad única

O - Principio abierto-cerrado

L - Principio de sustitución de Liskov

I - Principio de segregación de interfaces

D - Principio de inversión de dependencia

Como su implementación puede exceder el tiempo que quiere invertir en la lectura de este artículo, lo realizaremos por entregas.

Teoría

S – Principio de responsabilidad única

Una clase debe tener una y solo una razón para cambiar, lo que significa que una clase debe tener solo una responsabilidad.

O - Principio abierto-cerrado

Los objetos o entidades deben estar abiertos para la extensión, pero cerrados para la modificación.

Esto significa que una clase debe ser extensible sin modificar la clase misma.

L - Principio de sustitución de Liskov

Sea q(x) una propiedad demostrable sobre objetos de 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 significa que cada subclase o clase derivada debe ser sustituible por su clase base o padre.

I - Principio de segregación de interfaz

Nunca se debe obligar a un cliente a implementar una interfaz que no usa, o no se debe obligar a los clientes a depender de métodos que no usan, recomendables las interfaces especializadas a generales.

D - Principio de inversión de dependencia

 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 deben depender de abstracciones.

Este principio permite el desacoplamiento.

Conclusión

Implementar SOLID, nos ayudará a realizar software de mayor calidad, añadiendo muchas bondades a la práctica de construcción de software. Veremos en las siguientes 5 entregas mediante un caso práctico, como interiorizar SOLID y convertirlo en un hábito durante nuestros desarrollos.