SRP: qué es, el principio de responsabilidad única en el desarrollo

¿Qué es SRP (Single Responsibility Principle)?

SRP (Single Responsibility Principle) es el principio de responsabilidad única, que establece: cada clase o módulo debe tener exactamente una razón para cambiar. Esto no significa que una clase deba realizar exactamente una operación. Se refiere a un grupo de acciones relacionadas unidas por una única responsabilidad ante un actor.

Robert Martin reformuló SRP en términos de actores: una clase debe cambiar solo a petición de un interesado o un grupo de personas. Si dos actores diferentes requieren cambios en la misma clase, la responsabilidad está mal dividida.

Por ejemplo, una clase Employee que calcula el salario (solicitud del departamento de contabilidad) y genera informes (solicitud de la dirección) viola SRP. Cambiar las reglas de cálculo podría afectar la generación de informes y viceversa.

Definición formal de SRP

Un módulo debe tener una y solo una razón para cambiar. La razón del cambio la determina un actor — persona o sistema que inicia el requisito. Si los requisitos de diferentes actores provocan cambios en un mismo módulo, este viola SRP.

El concepto de actor convierte SRP en una herramienta práctica de análisis arquitectónico, no en una recomendación abstracta. Al diseñar un sistema, basta preguntarse: “¿Quién pedirá cambiar este código?” — si la respuesta incluye más de un interesado, la responsabilidad debe dividirse.

Cómo funciona el principio de responsabilidad única

La responsabilidad única se implementa agrupando métodos que cambian por una misma razón. La clase se convierte en un “punto de reunión” de lógica relacionada, no en una “navaja suiza” para todo. Esto simplifica la comprensión del código: el desarrollador ve la clase y comprende al instante su propósito.

El mecanismo de SRP se basa en la regla del eje único de cambio. Si una funcionalidad puede cambiar por razones independientes, debe extraerse en clases separadas. Las conexiones entre estas clases se construyen mediante composición o delegación.

La violación de SRP se manifiesta en “God Objects” — clases con decenas de métodos que trabajan con diferentes datos. Una clase así es difícil de probar: probar un método requiere configurar el entorno para todos los demás. Cambiar una responsabilidad puede romper otra, haciendo frágil el código.

En la práctica, SRP ayuda a los desarrolladores a responder la pregunta “¿dónde está este código?” Si cada responsabilidad está en su propia clase, encontrar el archivo correcto toma segundos. En un proyecto Android con arquitectura MVVM, UserViewModel solo se encarga del estado de la pantalla del usuario y UserRepository de la obtención de datos. Un desarrollador que busca la lógica de caché va a UserCacheRepository, no a ViewModel. Tal organización del código acelera la incorporación de nuevos miembros del equipo y reduce la cantidad de errores durante la refactorización.

Por qué SRP es importante en el desarrollo móvil

El desarrollo móvil exige una especial modularidad del código. Un Fragment de Android o un ViewController de iOS suele convertirse en un “imán” de lógica: manejo de toques, llamadas a la API, análisis de respuestas, actualización de la UI — todo en una misma clase. SRP exige separar estas responsabilidades.

En la arquitectura Android, SRP está integrado en las recomendaciones de Google sobre Jetpack: ViewModel se encarga del estado de la pantalla, Repository de los datos, UseCase de la lógica de negocio. Cada componente tiene una razón para cambiar. En el desarrollo iOS, los patrones MVVM y Coordinator siguen la misma lógica.

Seguir SRP en proyectos móviles aporta beneficios medibles: reducción del tamaño de las clases en un 40-60%, menor tiempo en code reviews y menos errores de regresión al añadir nuevas funcionalidades. Los módulos aislados son más fáciles de cubrir con pruebas unitarias y reutilizar en otras pantallas.

Impacto de SRP en las pruebas

Las pruebas unitarias de clases que cumplen SRP requieren menos objetos mock y menos configuración. Si una clase tiene una sola responsabilidad, sus dependencias son limitadas. La prueba verifica un comportamiento, no una combinación de varios escenarios no relacionados.

Según el informe de Google Testing Blog (2023), las clases con responsabilidad única muestran un 35% más de cobertura de pruebas en comparación con las clases agregadoras. Los desarrolladores escriben más fácilmente pruebas para módulos pequeños y comprensibles.

Ejemplos de SRP en Android e iOS

Veamos un ejemplo típico de clase Android que viola SRP — carga datos, analiza la respuesta y actualiza la UI. Tras la refactorización, cada responsabilidad se separa en su propio componente.

// Violación de SRP: una clase lo hace todo
class BadUserProfileActivity {
    fun loadUser(userId: Int) {
        // Solicitud HTTP
        // Análisis JSON
        // Actualización de UI
        // Guardado en BD
    }
}

// Después de aplicar SRP
class UserRepository {
    fun getUser(userId: Int): User
}

class UserViewModel {
    private val repo: UserRepository
    fun loadUser(userId: Int) { }
}

class UserProfileFragment {
    fun render(user: User) { }
}

Un ejemplo similar en iOS Swift con separación de la capa de red y la visualización:

// Violación de SRP: ViewController gestiona datos y UI
class BadProfileViewController: UIViewController {
    func viewDidLoad() {
        // Solicitud URLSession
        // Decodificar JSON
        // Actualizar label
    }
}

// Después de aplicar SRP
protocol UserServiceProtocol {
    func fetchUser(id: Int) async throws -> User
}

class ProfileViewModel {
    private let service: UserServiceProtocol
    func loadProfile(id: Int) { }
}

class ProfileViewController: UIViewController {
    func display(user: User) { }
}

La refactorización SRP no complica la arquitectura — redistribuye la responsabilidad. La cantidad de código puede incluso disminuir al eliminar duplicaciones. Cada nueva clase tiene un propósito claro y puede desarrollarse de forma independiente.

Composición como alternativa a la herencia

La composición ayuda a cumplir SRP donde la herencia crea acoplamientos innecesarios. En lugar de una superclase con decenas de métodos, la subclase recibe un conjunto de objetos especializados a través del constructor. Cada objeto se encarga de su propia funcionalidad.

En el desarrollo Android, el patrón Decorator permite añadir responsabilidades sin modificar la clase original. En iOS, una cadena de Middleware en la capa de red separa el registro, el almacenamiento en caché y la autenticación en módulos independientes.

Violaciones típicas de SRP y sus consecuencias

La violación más frecuente es una “God Class”: una clase que gestiona la base de datos, envía notificaciones, genera informes y procesa la entrada del usuario. Esta clase se convierte en un cuello de botella del proyecto: cualquier cambio requiere pruebas de regresión completas.

En el desarrollo móvil, la violación de SRP surge al mezclar lógica de negocio y lógica de UI en Activity, Fragment o ViewController. Cuando un onClickListener valida datos, llama a la API y actualiza la visibilidad de botones simultáneamente — es una violación directa del principio de responsabilidad única.

Las consecuencias de violar SRP incluyen: dificultad para el desarrollo en paralelo (conflictos en un mismo archivo), pruebas unitarias dificultadas, alto costo de modificaciones y menor legibilidad del código. Los proyectos con violaciones sistemáticas de SRP requieren 2-3 veces más tiempo para añadir nuevas funcionalidades.

Indicadores de violación de SRP en el código

Se pueden identificar violaciones de SRP por signos indirectos: una clase supera las 200 líneas, importa módulos de diferentes capas de la aplicación (UI + network + database), tiene más de 5 métodos públicos de distintas temáticas. La métrica de cohesión es un indicador estadístico: una baja cohesión de los métodos dentro de una clase señala una violación de SRP.

Para detectar violaciones de SRP, utiliza herramientas de análisis estático: para Android — Detekt con la regla TooManyFunctions, para iOS — SwiftLint con la regla file_length. Estas utilidades resaltan las clases que superan los umbrales de tamaño y complejidad.

La refactorización de clases que violan SRP se realiza mediante Extract Class o Extract Delegate: un grupo de métodos relacionados se extrae en una clase separada y la clase original les delega las llamadas. La aplicación gradual de estas refactorizaciones convierte una “God Class” en un conjunto de módulos débilmente acoplados, cada uno con una única responsabilidad. Este enfoque permite mejorar la arquitectura sin detener el desarrollo: la refactorización se realiza de forma iterativa, un módulo a la vez.