Qué es el Single Responsibility Principle

El principio de responsabilidad única es el primero de los principios SOLID y establece que cada componente de tu sistema, ya sea una clase, un método o un microservicio, debe encargarse de una sola cosa. Si programas en C# o trabajas con arquitecturas modernas, dominar este principio te ayuda a escribir código más claro, mantenible y fácil de escalar.

Qué es el Single Responsibility Principle y por qué importa

En inglés se conoce como Single Responsibility Principle y conviene que recuerdes el término exacto. En entrevistas técnicas suelen mencionarlo así, y la documentación más profunda sobre escenarios avanzados también está en inglés [0:18].

La idea central es sencilla: distribuir las responsabilidades del sistema entre diferentes componentes. Cada pieza tiene un trabajo y solo uno.

¿Qué dice el principio de responsabilidad única? Que cada clase, método o módulo debe tener una sola razón para existir y una sola responsabilidad bien definida dentro del sistema.

Cómo se aplica el principio en clases, métodos y microservicios

En programación orientada a objetos con C#, el principio se traduce en reglas concretas para cada nivel del código. Las clases deben representar un único modelo y hacer una única cosa. Los métodos también deben ejecutar una sola tarea, y tanto el nombre de la clase como el del método deben describir con precisión esa responsabilidad [1:10].

Esto aplica a todos los niveles del sistema:

• Módulos.
• Clases.
• Métodos y funciones.
• Librerías que integras.
• Microservicios completos en arquitecturas distribuidas.

Cuando trabajas con microservicios, cada servicio debería resolver un único dominio o función. Es el mismo principio escalado a la arquitectura [1:55].

Cómo identificar responsabilidades en una historia de usuario

Aquí viene la parte práctica. Imagina esta historia de usuario tomada del curso: "Como usuario, luego de confirmar la compra, espero ver un mensaje de confirmación, tener la posibilidad de descargar la factura y un correo electrónico de confirmación" [2:25].

A primera vista parece una sola acción, pero si la analizas con calma encuentras tres responsabilidades distintas que se disparan tras el mismo evento.

Las tres responsabilidades del ejemplo del carrito de compras

Cuando un usuario finaliza un pago en una tienda online, el sistema debe ejecutar tareas separadas:

1. Mostrar el mensaje de confirmación y guardar la trazabilidad en base de datos.
2. Generar y permitir la descarga de la factura o comprobante de pago.
3. Enviar el correo electrónico de confirmación al cliente.

Aunque las tres acciones ocurren tras el mismo evento, no deberías meterlas en una sola clase con un método gigante. La clave está en distribuirlas entre componentes distintos, o incluso entre microservicios distintos si tu arquitectura lo permite [3:30].

¿Por qué separar responsabilidades en componentes distintos? Porque si una funcionalidad cambia, como el formato del correo o la generación de la factura, solo modificas el componente responsable sin tocar el resto del flujo.

Cómo se ve un código que rompe el principio

El demo del curso parte de una clase llamada StudentRepository que administra los datos del modelo estudiante, pero que actualmente no cumple con el principio de responsabilidad única [4:35]. La idea es analizar qué hace esa clase, identificar dónde está mezclando responsabilidades y refactorizarla.

Este tipo de ejercicio entrena tu ojo para detectar señales de alerta como:

• Clases con nombres genéricos que esconden múltiples tareas.
• Métodos que hacen validaciones, persistencia y notificaciones a la vez.
• Cambios pequeños en una funcionalidad que rompen otras partes del sistema.

Cuando detectas estas señales, sabes que es momento de dividir esa clase en piezas más pequeñas, cada una con un nombre descriptivo y una responsabilidad clara. Cuéntame en los comentarios qué clase de tu proyecto actual crees que está rompiendo este principio.