Introducción.
En el principio Dahl y Nygaard crearon la programación orientada a objetos. Y esta se encontraba desordenada y vacía, y las tinieblas estaban sobre la faz de la programación. Pero entonces Robert C. Martin, habló a los congregados y les dijo:
"Aquí tenéis los 5 mandamientos de la programación orientada a objetos. No son verdades absolutas y no siempre podrán vivir conjuntamente. Usadlos con mi beneplácito".
Ejem.... perdón, que quería realizar una idealización de nuestro pasado en la programación. Así que dejemos las introducciones grandilocuentes para comenzar a hablar de SOLID. ¿Qué es? ¿Con que fin nace?.
SOLID es un conjunto de prácticas propuestas por Robert C. Martin con el fin de resolver los problemas existentes en las aplicaciones desarrolladas mediante programación orientada a objetos (POO), y así hacerlas más sencillas de leer, mantener y testear. El acrónimo se compone de las iniciales de cada uno de los cinco principios o prácticas que lo conforman:
En muchas ocasiones, al buscar información sobre estos principios en la red, se encuentran datos poco claros o artículos demasiado extensos que generan más dudas que respuestas. Por esta razón, hemos creado una serie de cinco artículos en los que explicaremos cada uno de los principios de forma clara y práctica, para que puedas saber cuándo, cómo y por qué aplicarlos en tus proyectos.
Cabe destacar que estos principios, no quedan relegados a las clases, se puede aplicar a otros ámbitos.
(S) Principio de responsabilidad única.
"Una clase debería tener una, y sólo una, razón para cambiar"
Robert C. Martin
Una clase sólo debería hacer una única cosa, es decir, tener sólo una responsabilidad. Si hacemos que una clase se encargue de todo, cualquier cambio en la funcionalidad requerirá de modificaciones en dicha clase, e incluso en partes en las que no debería cambiar.
Para detectar si estamos cumpliendo este principio, podemos hacernos varias preguntas:
- ¿La clase es muy grande? Normalmente, esto puede indicar que está haciendo demasiadas cosas.
- ¿Cualquier cambio en otras capas del código requieren cambios en la clase? Esto implica que la clase está llevando a cabo funciones de capas de la arquitectura que no debería ni saber que existen. Por ejemplo, que una clase con información de usuario tenga métodos de guardado de en base de datos. ¿Por qué debería cambiar la clase Usuario si cambia la base de datos o las consultas?
- ¿Por qué tengo "grupos" de atributos en la clase que no parecen estar relacionados entre sí? Volviendo al ejemplo del punto anterior, ¿qué hace un atributo dbConnector en mi clase Usuario?
- ¿Por qué tengo que configurar medio entorno para testear sólo esta clase? A excepción de que quisieras hacer una prueba de la clase que carga toda tu aplicación, en la clase Usuario no debería ser necesario configurar o mockear una gran cantidad de elementos para crear pruebas unitarias.
Para ilustrar este punto, podemos tomar como ejemplo una clase mal diseñada llamada TextDocument, que contiene las propiedades de un documento y también se encarga de compartirlos:
La clase presenta un problema al tener dos responsabilidades. Por un lado, gestiona el documento y, por otro, se encarga de compartirlo. ¿Realmente es algo que el documento debe saber? Y es que el compartir no es algo relativo a las propiedades de un documento, sino es una acción para realizar otro fin, por lo que esta responsabilidad no debería ser del documento. Es más, esta parte estaría muy acoplada a la forma de compartir, no es lo mismo enviar por correo electrónico que compartir por Bluetooth. Por lo que volvemos a preguntarnos, ¿un documento debe saber que hay correo electrónico y Bluetooth en nuestro proyecto? La respuesta es bien sencilla, no debe saber nada del exterior o de lo que puedan hacer con él. Debe vivir en su mundo aislado cual hikikomori.
Para solucionar este problema, dejamos que TextDocument tenga sólo la responsabilidad de operar con un documento, y además creamos una clase que se encargue exclusivamente de compartir documentos. Yendo más allá, En lugar de tener una sola clase, podemos separar las responsabilidades en diferentes clases, como EmailSharer y BluetoothSharer. De esta forma, tenemos una estructura que se puede probar fácilmente y que además está desacoplada por funcionalidades.
En resumen, el Principio de Responsabilidad Única nos ayuda a crear clases más cohesivas y modulares, lo que facilita la comprensión, mantenimiento y prueba de nuestro código.
En el siguiente artículo pasaremos a la letra O: Open/Closed Principle. Cualquier duda, comentario o corrección podéis dejarla en comentarios; y si para ti hay mucho texto, puedes ver el resumen en este post de Instagram.
Más artículos de esta serie:
Capítulo O: Open/Closed Principle
Capítulo L: Liskov Substitution Principle
Capítulo I: Interface-Segregation Principle
Capítulo D: Dependency Inversion Principle
Comparte este artículo con quien quieras
Introducción.
En el principio Dahl y Nygaard crearon la programación orientada a objetos. Y esta se encontraba desordenada y vacía, y las tinieblas estaban sobre la faz de la programación. Pero entonces Robert C. Martin, habló a los congregados y les dijo:
Ejem.... perdón, que quería realizar una idealización de nuestro pasado en la programación. Así que dejemos las introducciones grandilocuentes para comenzar a hablar de SOLID. ¿Qué es? ¿Con que fin nace?.
SOLID es un conjunto de prácticas propuestas por Robert C. Martin con el fin de resolver los problemas existentes en las aplicaciones desarrolladas mediante programación orientada a objetos (POO), y así hacerlas más sencillas de leer, mantener y testear. El acrónimo se compone de las iniciales de cada uno de los cinco principios o prácticas que lo conforman:
En muchas ocasiones, al buscar información sobre estos principios en la red, se encuentran datos poco claros o artículos demasiado extensos que generan más dudas que respuestas. Por esta razón, hemos creado una serie de cinco artículos en los que explicaremos cada uno de los principios de forma clara y práctica, para que puedas saber cuándo, cómo y por qué aplicarlos en tus proyectos.
(S) Principio de responsabilidad única.
Una clase sólo debería hacer una única cosa, es decir, tener sólo una responsabilidad. Si hacemos que una clase se encargue de todo, cualquier cambio en la funcionalidad requerirá de modificaciones en dicha clase, e incluso en partes en las que no debería cambiar.
Para detectar si estamos cumpliendo este principio, podemos hacernos varias preguntas:
Para ilustrar este punto, podemos tomar como ejemplo una clase mal diseñada llamada TextDocument, que contiene las propiedades de un documento y también se encarga de compartirlos:
La clase presenta un problema al tener dos responsabilidades. Por un lado, gestiona el documento y, por otro, se encarga de compartirlo. ¿Realmente es algo que el documento debe saber? Y es que el compartir no es algo relativo a las propiedades de un documento, sino es una acción para realizar otro fin, por lo que esta responsabilidad no debería ser del documento. Es más, esta parte estaría muy acoplada a la forma de compartir, no es lo mismo enviar por correo electrónico que compartir por Bluetooth. Por lo que volvemos a preguntarnos, ¿un documento debe saber que hay correo electrónico y Bluetooth en nuestro proyecto? La respuesta es bien sencilla, no debe saber nada del exterior o de lo que puedan hacer con él. Debe vivir en su mundo aislado cual hikikomori.
Para solucionar este problema, dejamos que TextDocument tenga sólo la responsabilidad de operar con un documento, y además creamos una clase que se encargue exclusivamente de compartir documentos. Yendo más allá, En lugar de tener una sola clase, podemos separar las responsabilidades en diferentes clases, como EmailSharer y BluetoothSharer. De esta forma, tenemos una estructura que se puede probar fácilmente y que además está desacoplada por funcionalidades.
En resumen, el Principio de Responsabilidad Única nos ayuda a crear clases más cohesivas y modulares, lo que facilita la comprensión, mantenimiento y prueba de nuestro código.
En el siguiente artículo pasaremos a la letra O: Open/Closed Principle. Cualquier duda, comentario o corrección podéis dejarla en comentarios; y si para ti hay mucho texto, puedes ver el resumen en este post de Instagram.
Más artículos de esta serie:
Capítulo O: Open/Closed Principle
Capítulo L: Liskov Substitution Principle
Capítulo I: Interface-Segregation Principle
Capítulo D: Dependency Inversion Principle
jose