Single responsibility

El principio de Responsabilidad Única (Single Responsibility Principle – SRP) es uno de los principios SOLID y se refiere a que una clase debe tener una y solo una razón para cambiar. Esto significa que una clase debe tener una responsabilidad específica y no debería tener varias responsabilidades.

Por ejemplo:

1. Una clase BankAccount que se encarga de llevar el control de las operaciones bancarias (depósitos, retiros, transferencias) y también maneja la impresión de los estados de cuenta. Es mejor dividir esta clase en dos clases distintas: BankAccount y BankAccountPrinter para que cada una tenga una única responsabilidad.
2. Una clase Car que se encarga de la lógica de conducción y también maneja la lógica de diseño del automóvil. Es mejor dividir esta clase en dos clases distintas: Car y CarDesign para que cada una tenga una única responsabilidad.
3. Una clase Employee que se encarga de manejar el registro de empleados y también maneja el cálculo de salarios. Es mejor dividir esta clase en dos clases distintas: Employee y SalaryCalculator para que cada una tenga una única responsabilidad.

En resumen, al aplicar el principio de Responsabilidad Única, se logra que las clases sean más fáciles de entender, de probar y de mantener, ya que su responsabilidad esta claramente definida y es menos probable que un cambio en una parte del sistema afecte otras partes del mismo.

Aquí te dejo un ejemplo de código en Java que ilustra el principio de Responsabilidad Única:

class BankAccount {
    private double balance;

    public void deposit(double amount) {
        balance += amount;
    }

    public void withdraw(double amount) {
        balance -= amount;
    }

    public double getBalance() {
        return balance;
    }

    // viola el principio SRP, una clase debería tener solo una razón para cambiar
    public void printStatement() {
        // lógica de impresión del estado de cuenta
    }
}

En este ejemplo, la clase BankAccount tiene varias responsabilidades: manejar las operaciones bancarias (depósitos, retiros) y manejar la impresión del estado de cuenta. Esto viola el principio de Responsabilidad Única, ya que si hay un cambio en la lógica de impresión del estado de cuenta, tendría que modificar la clase BankAccount, aun si no tiene nada que ver con las operaciones bancarias.

Una forma de solucionar esto es dividir la clase en dos:

class BankAccount {
    private double balance;

    public void deposit(double amount) {
        balance += amount;
    }

    public void withdraw(double amount) {
        balance -= amount;
    }

    public double getBalance() {
        return balance;
    }
}

class BankAccountPrinter {
    public void printStatement(BankAccount account) {
        // lógica de impresión del estado de cuenta
    }
}

De esta forma, cada clase tiene una responsabilidad específica y es menos probable que un cambio en una parte del sistema afecte otras partes del mismo.

https://www.geeksforgeeks.org/single-responsibility-principle-in-java-with-examples/

https://howtodoinjava.com/design-patterns/single-responsibility-principle/

Real-Time Examples of Single Responsibility Principle in C#