Principios SOLID desmitificados — Introducción

La creación de software complejo es a la vez emocionante y desafiante, pero es aún más desafiante y deprimente cuando se realiza el mantenimiento y la actualización de un software mal escrito.

La metodología en la que escribimos un código excelente y bien estructurado es siguiendo y adhiriéndose a un conjunto de principios llamados Principios SOLID .

Los principios SOLID fueron presentados por primera vez por el científico informático Robert C. Martin en su artículo publicado en 2000.

Veamos el acrónimo SOLID:

(S) principio de responsabilidad ←

Una clase solo debe ser responsable de un solo propósito, lo que significa que una clase solo debe tener un tipo de trabajo para realizar, como (lógica de base de datos, lógica de registro, etc.).

Principio (O)abierto/Cerrado ←

Una clase debe estar abierta para la extensión y cerrada para la modificación, lo que significa que una clase existente debe ser extensible sin tener que reescribirla para implementar una nueva funcionalidad.

(L) Principio de sustitución de iskov ←

Las clases principales deben poder sustituirse fácilmente por sus clases secundarias, lo que significa que si la clase Rectangle es un subtipo de la clase Shape, deberíamos poder reemplazar Shape con Rectangle sin interrumpir el flujo funcional.

(I) Principio de segregación de interfaces ←

Las interfaces no deben obligar a las clases a implementar una funcionalidad que no admiten, lo que significa que las interfaces más grandes deben dividirse en otras más pequeñas para ofrecer soporte.

(D) Principio de inversión de dependencia ←

Las clases deben depender de la abstracción pero no de la concreción, lo que significa que los módulos de alto nivel no deben depender de los módulos de bajo nivel. Ambos deben depender de la abstracción.