Introducción a S.O.L.I.D
En esta entrada, intentaremos abordar un nuevo ciclo de conceptos que tienen que ver sobre los principios SOLID, que son fundamentales en la programación orientada a objetos o POO. Estos principios fueron formulados, en principio, por Robert C. Martin, también conocido como "Uncle Bob", con el objetivo de mejorar la mantenibilidad y escalabilidad del código de software. SOLID es un acrónimo que representa cinco principios de diseño:
- Single Responsibility Principle (SRP) – Principio de Responsabilidad Única
- Open/Closed Principle (OCP) – Principio de Abierto/Cerrado
- Liskov Substitution Principle (LSP) – Principio de Sustitución de Liskov
- Interface Segregation Principle (ISP) – Principio de Segregación de Interfaces
- Dependency Inversion Principle (DIP) – Principio de Inversión de Dependencias
Estos principios nos ayudan a crear software más modular, flexible y fácil de mantener. En este artículo, nos vamos a enfocar en el primero de ellos: el Principio de Responsabilidad Única (SRP).
Así que vamos allá.
¿Qué es el Principio de Responsabilidad Única (SRP)?
El Principio de Responsabilidad Única establece que una clase debe proporcionar solo una funcionalidad, no más de una.
Por ejemplo, si una clase implementa validaciones, recuperación de datos desde la configuración y acceso a la base de datos, está manejando múltiples responsabilidades, lo cual es una mala práctica. En su lugar, cada funcionalidad debe implementarse en una clase separada: una para acceso a datos, otra para validaciones, otra para manejo de caché, otra para manipulación de cookies, y otra para manejar solicitudes de usuario.
El problema de incluir múltiples funcionalidades en una sola clase es que el código se vuelve difícil de mantener, depurar e identificar errores. Además, si se necesita extender o modificar una funcionalidad existente, habría que hacer cambios en la misma clase, lo que podría afectar otras funcionalidades. Esto obligaría a reescribir casos de prueba, ya que los existentes podrían no ser relevantes con el código actualizado. También complica el trabajo en equipo, ya que sería difícil dividir tareas en equipos independientes.
Para evitar estos problemas, el SRP recomienda que una clase tenga solo un motivo para cambiar, es decir, que implemente una única funcionalidad.
Como beneficio, las clases serán independientes, fáciles de entender, modificar, diseñar, escribir, mantener y probar.
Un ejemplo típico de violación del SRP es una clase que implementa tanto la lectura de configuraciones como validaciones de modelos. En este caso, es recomendable dividir el código en dos clases separadas:
- Una clase para la validación.
- Otra clase para la lectura de configuración.
Sin embargo, esto no significa que una clase no pueda llamar a métodos de otra clase. Por ejemplo, una clase puede llamar un método de otra cuando sea necesario, pero sin acoplarse completamente a su código.
Veamos un mal ejemplo en C# donde se viola este principio:
public class ReportManager
{
public void GenerateReport()
{
// Genera el informe
Console.WriteLine("Generando el informe...");
}
public void SaveToFile(string content)
{
// Guarda el informe en un archivo
File.WriteAllText("reporte.txt", content);
}
public void SendEmail(string email)
{
// Envía el informe por correo
Console.WriteLine($"Enviando el informe a {email}");
}
}Acá, la clase ReportManager tiene tres responsabilidades:
- Generar un informe.
- Guardar el informe en un archivo.
- Enviar el informe por correo.
Esto hace que la clase sea difícil de mantener, ya que un cambio en la lógica de almacenamiento o en la lógica de envío podría afectar la generación del informe.
Aplicando el Principio de Responsabilidad Única
Para corregir el problema del ejemplo anterior, podemos separar las responsabilidades en clases independientes:
public class ReportGenerator
{
public string GenerateReport()
{
return "Este es un informe generado.";
}
}
public class ReportSaver
{
public void SaveToFile(string content)
{
File.WriteAllText("reporte.txt", content);
}
}
public class EmailService
{
public void SendEmail(string email, string content)
{
Console.WriteLine($"Enviando el informe a {email}");
}
}Ahora cada clase tiene una única responsabilidad, haciendo que el código sea más modular y fácil de modificar sin afectar otras partes del sistema.
Finalmente, podemos coordinar estas clases en un servicio central:
public class ReportManager
{
private readonly ReportGenerator _generator;
private readonly ReportSaver _saver;
private readonly EmailService _emailService;
public ReportManager()
{
_generator = new ReportGenerator();
_saver = new ReportSaver();
_emailService = new EmailService();
}
public void ProcessReport(string email)
{
var report = _generator.GenerateReport();
_saver.SaveToFile(report);
_emailService.SendEmail(email, report);
}
}Ahora, si necesitamos cambiar la forma en que se genera el informe, almacenamos los archivos o enviamos correos electrónicos, podemos hacerlo sin afectar el resto del código.
El Principio de Responsabilidad Única nos ayuda a estructurar mejor nuestro código, facilitando su mantenimiento y evitando problemas derivados de la alta interdependencia entre funciones. En el próximo artículo, vamos a ver qué nos plantea el Principio de Abierto/Cerrado (OCP), que es el segundo en aparición en S.O.L.I.D. Hasta la próxima.
