Existen 5 principios SOLID, que explicaremos a continuación qué son. En este post hablaremos del primero: Single-responsibility principle.
¿Qué son los principios SOLID?
Los principios SOLID son una serie de principios básicos de la programación orientada a objetos y el diseño de software. Cuando se utilizan estos principios se consigue un software con mayor mantenibilidad y, por lo tanto, con mayor vida. Los 5 principios de programación son: Single-responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion. De la primera letra de cada uno se crea el acrónimo que los une: SOLID.
Single-responsibility principle
En esta exploración detallada, vamos a hablar sobre el primero de los muy conocidos, principios SOLID: el principio de responsabilidad única.
Este principio, fue introducido por Robert C.Martin en el artículo “The Principles of the OOD”, en el indicaba que: “Una clase debe tener una, y solamente una razón, para cambiar”.
Si conseguimos que nuestras clases únicamente tengan una responsabilidad y, además, esta responsabilidad está definida y es concreta, el único motivo por el cual esta clase podría necesitar cambiar es que exista un cambio de lógica de negocio que la afecte.
Cómo detectar que estamos violando el principio de responsabilidad única
En la travesía hacia la aplicación efectiva del principio de responsabilidad única, es fundamental poseer las herramientas adecuadas para detectar posibles violaciones.
Para ello, disponemos de varios mecanismos que nos pueden ayudar a detectar que no estamos cumpliendo este principio. A continuación, detallamos algunos de los síntomas que nos pueden ayudar a detectarlos.
- Clases con demasiadas líneas de código.
- Cuando se nos indica un cambio tenemos que modificar en muchos ficheros.
- No cumplir la separación de capas en la arquitectura de software.
- No analizar bien las responsabilidades a la hora de desarrollar software.
- Al explicar que hace la clase se enumera más de una responsabilidad.
- Tener más de un método público.
- Dificultad a la hora de testear la clase.
Estos indicadores no solo sirven como alertas, sino que también apuntan hacia áreas específicas que podrían beneficiarse de una mayor atención y claridad. La maestría en la identificación de estos síntomas es esencial para mantener una base sólida de diseño de software fundamentada en los principios SOLID.
Ejemplo:
Imaginemos que tenemos la siguiente clase:
class User {
constructor(private readonly _name: string, private readonly _email: string) {}
get name(): string {
return this._name;
}
get email(): string {
return this._email;
}
sendWelcomeEmail(): void {
// Lógica de envío de email
}
}Esta clase tiene claramente dos responsabilidades, la obtención de manejo de datos del usuario y el envío de email de bienvenida del usuario.
Si se quisiera realizar una modificación en el envío de email, también se vería afectada la clase de la obtención de datos, ya que es la misma.
Para solucionar esto, deberíamos tener 2 clases, una para la obtención de datos del usuario y otra para el envío de email:
class User {
constructor(private readonly _name: string, private readonly _email: string) {}
get name(): string {
return this._name;
}
get email(): string {
return this._email;
}
}class Mailer {
sendWelcomeEmail(user: User): void {
// Lógica de envío de email
}
}De esta forma, cualquier cambio que haya en el envío de email o en la obtención de datos del usuario únicamente repercuten en la clase encargada de ello.
En los próximos artículos de nuestro blog, nos sumergiremos en los restantes cuatro principios SOLID: Open-closed, Liskov substitution, Interface segregation y Dependency inversion. Cada uno de estos principios juega un papel esencial en la creación de un software robusto y flexible. Desglosaremos su significado, exploraremos ejemplos prácticos y brindaremos consejos sobre cómo aplicarlos efectivamente en tu desarrollo de software. Mantente atento a próximos contenidos.
