Hoy me gustaría hablar sobre SOLID, los primeros cinco principios de la programación orientada a objetos que consideramos esenciales para crear software de trabajo. En caso de que no lo supiera, en la programación de computadoras, Michael Feathers introdujo el acrónimo de principios SOLID para cinco principios que fueron definidos por Robert C. Martin a principios de la década de 2000.
Como saben, para obtener un software que funcione, debemos tener un bajo acoplamiento, alta cohesión y una fuerte encapsulación, que es algo que los principios SOLID nos ayudan a obtener. La idea es que, al aplicar esos principios juntos, puede escribir código de mejor calidad que sea robusto. El sistema creado se vuelve fácil de mantener, reutilizar y extender con el tiempo. Básicamente, los principios SOLID ayudan a los desarrolladores de software a lograr escalabilidad y evitar que su código se rompa cada vez que se enfrente a un cambio.
OK, así que comencemos con lo básico, SOLID significa:
S – Principio de responsabilidad única
O – Principio abierto-cerrado
L – Principio de sustitución de Liskov
I – Principio de segregación de interfaz
D – Principio de inversión de dependencia
Miremos cada principio individualmente para comprender por qué SOLID puede ayudar a los desarrolladores a desarrollar software de calidad.
Los principios sólidos
1.Principio de responsabilidad única
"Nunca debe haber más de una razón para que una clase cambie".
Como puede ver, este principio establece que un objeto / clase solo debe tener una responsabilidad y que debe estar completamente encapsulado por la clase. Aquí, cuando hablamos de una responsabilidad, queremos decir una razón para cambiar. Este principio conducirá a una cohesión más fuerte en la clase y un acoplamiento más flexible entre las clases de dependencia, una mejor legibilidad y un código con una menor complejidad.
Es mucho más difícil entender y editar una clase cuando tiene varias responsabilidades. Entonces, si tenemos más de una razón para cambiar, la funcionalidad se dividirá en dos clases y cada una manejará su propia responsabilidad.
Nos preocupamos por separar las funcionalidades porque cada responsabilidad es un acceso de cambio. Cuando una clase tiene más de una responsabilidad, esas responsabilidades se acoplan y este acoplamiento puede conducir a una base de código frágil que es difícil de refactorizar cuando surgen sus requisitos.
2. Principio abierto-cerrado
"Las entidades de software (clases, módulos, funciones, etc.) deben estar abiertas para extensión, pero cerradas para modificación".
Aquí, la idea es que una entidad permita que su comportamiento se extienda pero nunca modificando su código fuente. Cualquier clase (o lo que sea que escriba) debe escribirse de tal manera que pueda usarse como está. Se puede extender si es necesario, pero nunca se puede modificar. Puedes considerar esto cuando estés escribiendo tus clases. Use la clase de la forma que necesite, pero modificar su comportamiento se produce agregando un nuevo código, nunca modificando el antiguo. El mismo principio se puede aplicar para módulos, paquetes, bibliotecas.
Al aplicar el principio de abrir-cerrar, obtendrá un acoplamiento suelto, mejorará la legibilidad y, por último, reducirá el riesgo de romper la funcionalidad existente.
3. Principio de sustitución de Liskov
"los subtipos deben ser sustituibles por sus tipos base"
Como lo dice su nombre, el Principio de Sustitución de Likov fue definido por Barbara Liskov . La idea aquí es que los objetos deben ser reemplazables por instancias de sus subtipos, y eso sin afectar el funcionamiento de su sistema desde el punto de vista del cliente. Básicamente, en lugar de usar la implementación real, siempre debe poder usar una clase base y obtener el resultado que estaba esperando. A menudo, cuando queremos representar un objeto, modelamos nuestras clases en función de sus propiedades y, en lugar de eso, deberíamos centrarnos más en los comportamientos.
Este principio básicamente confirma que nuestras abstracciones son correctas y nos ayuda a obtener un código que es fácilmente reutilizable y jerarquías de clase que se entienden muy fácilmente.
Lo que muchos dicen es que el Principio de sustitución de Liskov tiene una relación muy fuerte con el principio anterior, el principio abierto-cerrado. Robert C. Martin incluso dice que "una violación de LSP es una violación latente de OCP".
4. Principio de segregación de interfaz
"Las clases que implementan interfaces no deberían verse obligadas a implementar métodos que no utilizan".
Aquí, se trata de cómo escribir interfaces. Entonces, ¿qué se dice? Básicamente, una vez que una interfaz se está volviendo demasiado grande / gruesa, necesitamos dividirla en pequeñas interfaces que sean más específicas. Y la interfaz será definida por el cliente que la usará, lo que significa que el cliente de la interfaz solo sabrá acerca de los métodos relacionados con ellos.
En realidad, si agrega métodos que no deberían estar allí, las clases que implementan la interfaz también deberán implementar esos métodos. Es por eso que; el cliente no debería verse obligado a depender de las interfaces que no utiliza. El objetivo de ISP es mantener un sistema desacoplado y, por lo tanto, más fácil de refactorizar, cambiar e implementar.
5. Principio de inversión de dependencia
"Los módulos de alto nivel no deberían depender de módulos de bajo nivel, sino que ambos deberían depender de la abstracción. La abstracción no debería depender de los detalles; más bien, el detalle debería depender de la abstracción".
Último de los principios SÓLIDOS, pero no menos importante, este principio se ocupa principalmente de reducir las dependencias entre los módulos de código. Básicamente, el Principio de Inversión de Dependencia será de gran ayuda cuando se trata de comprender cómo vincular correctamente su sistema.
Si los detalles de su implementación dependerán de las abstracciones de nivel superior, le ayudará a obtener un sistema que esté acoplado correctamente. Además, influirá en la encapsulación y la cohesión de ese sistema.
Conclusión
Al desarrollar cualquier software, hay dos conceptos que son muy importantes: cohesión (cuando diferentes partes de un sistema trabajarán juntas para obtener mejores resultados que si cada parte estaría trabajando individualmente) y acoplamiento (puede verse como un grado de dependencia de una clase, método o cualquier otra entidad de software).
El acoplamiento generalmente está presente en una gran cantidad de código y, como mencioné anteriormente, la situación óptima sería tener un bajo acoplamiento y una alta cohesión. Con esta breve introducción a los 5 principios SÓLIDOS, debe haber entendido que nos ayudan cuando se trata de eso.
Hay muchos principios en ingeniería de software y recomendaría que antes de escribir un código, investigue, lea e intente comprender los principios. Aunque parezca mucho, SOLID se convierte en una parte de usted y su código al usarlo continuamente y adaptar sus pautas.