Principios SOLID

SOLID es un conjunto de buenas practicas, creado para la programación orientada a objetos, también se puede ver como una guía de estilos de programación.

Este principio es importante dentro la codificación de software dado que nos permite:

• Tener un código fácil de probar (Pruebas Unitarias).
• El código se vuelve más reutilizable.
• El código es más ordenado y fácil de leer (KISS).
• No repetir unidades de código (DRY).

En términos de calidad SOLID nos garantiza, menos Bug y mayor flexibilidad en el código, permitiendo así cambiar el código de manera más fácil y controlada.

Dentro de este principio se da una guía de estilos de programación, no son reglas a seguir, las cuales son mencionadas a continuación:

Single Responsability (SRP)

Esta guía determina que clases y métodos solo deben tener una y solo una responsabilidad, para ello se deben tener en cuenta las siguientes recomendaciones:

• Clases y métodos grandes dificultan el mantenimiento del código.
• Clases y métodos grandes son difíciles de leer.
• El código debe ser reutilizable.
• Clases y métodos pequeños aportan flexibilidad y disminuyen la cantidad de código repetido.
• Se debe evitar la complejidad innecesaria.
• Tener mayor número de clases no significa mayor complejidad.

Open Closed (OCP)

Esta guía determina que clases, módulos y métodos deben estar abiertos (Open) para su extensión pero cerrados (Closed) para la modificación.

"Una clase está cerrada, dado que puede ser compilada, almacenada en una librería, y usada por otras clases cliente; Pero también está abierta, dado que a partir de ella, podríamos crear nuevas subclases que incorporaran características nuevas. Y al crear una subclase, no hay ninguna necesidad de modificar las clases cliente de la super clase" (Meyer, Bertrand, 1988, p 229).

Liskov Substitution (LSP)

Esta guía afirma que al tener objetos de tipos diferentes los cuales se derivan de una misma clase base–, deberíamos poder reemplazar cada uno de los los tipos derivados por la base–, no obstante al momento de realizar la substitución deben estar contemplados todos los escenarios para no encontrase con resultados inesperados.

Interface Segregation (ISP)

Esta guía  sugiere utilizar el principio de Single Responsability, pero aplicado a la definición de interfaces, es decir, no utilizar interfaces con un propósito general y si utilizar varias con propósitos específicos, permitiendo así flexibilidad en la modificación del código.

Dependency Inversion (DIP)

Esta guía sugiere buscar al momento del diseño de un sistema  tener un bajo acoplamiento y una alta cohesión; para ello se debe tener en cuenta lo siguiente:

• La abstracción no debe depender de los detalles. Los detalles deben depender de la abstracción.
• Clases fuertemente acopladas no pueden trabajar independientemente una de la otra.
• La inyección de dependencias (DI) es uno de los patrones que siguen este principio.