Jede Softwarekomponente sollte nur eine und eine Verantwortung haben

Softwarekomponente kann eine Klasse, Methode oder ein Modul sein

Beispiel: Ein Schweizer Taschenmesser ist ein Mehrzweckwerkzeug, das gegen das Prinzip der Einzelverantwortung der Softwareentwicklung verstößt. Stattdessen ist ein Messer ein gutes Beispiel, das der Einzelverantwortung folgt (da es im Gegensatz zum Schweizer Taschenmesser nur zum Schneiden verwendet werden kann). das zum Schneiden, Öffnen von Dosen, als Hauptschlüssel, als Schere usw. verwendet werden kann)

Da der Wandel konstant ist, sei es in der realen Welt oder in der Softwareentwicklung, ändert sich auch die Definition des Single-Responsibility-Prinzips entsprechend

Jede Softwarekomponente sollte einen und nur einen Grund zur Änderung haben

Es gibt drei Gründe, aus denen Änderungen in der folgenden Klasse „Mitarbeiter“ auftreten können

1. Änderung im Mitarbeiterattribut
2. Änderung in der Datenbank
3. Änderung der Steuerberechnung

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.Statement;

/**
 * Employee class has details of employee
 * This class is responsible for saving employee details, getting tax of
 * employee and getting
 * details of employee like name, id, address, contact, etc.
 */
public class Employee {
    private String employeeId;
    private String employeeName;
    private String employeeAddress;
    private String contactNumber;
    private String employeeType;

    public void save() {
        String insert = MyUtil.serializeIntoString(this);
        Connection connection = null;
        Statement statement = null;
        try {
            Class.forName("com.mysql.jdbc.Driver");
            connection = DriverManager.getConnection("jdbc://mysql://localhost:8080/MyDb", "root", "password");
            statement = connection.createStatement();
            statement.execute("insert into employee values ("   insert   ")");

        } catch (Exception e) {
            e.printStackTrace();
        }

    }

    public void calculateTax() {
        if (this.getEmployeeType().equals("fulltime")) {
            // tax calculation for full time employee
        } else if (this.getEmployeeType().equals("contract")) {
            // tax calculation for contract type employee
        }
    }

    public String getEmployeeId() {
        return employeeId;
    }

    public void setEmployeeId(String employeeId) {
        this.employeeId = employeeId;
    }

    public String getEmployeeName() {
        return employeeName;
    }

    public void setEmployeeName(String employeeName) {
        this.employeeName = employeeName;
    }

    public String getEmployeeAddress() {
        return employeeAddress;
    }

    public void setEmployeeAddress(String employeeAddress) {
        this.employeeAddress = employeeAddress;
    }

    public String getContactNumber() {
        return contactNumber;
    }

    public void setContactNumber(String contactNumber) {
        this.contactNumber = contactNumber;
    }

    public String getEmployeeType() {
        return employeeType;
    }

    public void setEmployeeType(String employeeType) {
        this.employeeType = employeeType;
    }

}

Da das SRP (Single Responsibility Principle) nur einen Grund für Änderungen in der Klasse empfiehlt, müssen wir einige Änderungen in der Mitarbeiterklasse vornehmen

Änderungen durch SRP

Jetzt gibt es nur einen Grund, warum Änderungen in der Mitarbeiterklasse auftreten können

Grund für die Änderung: Änderung im Mitarbeiterattribut

/**
 * Employee class has details of employee
 */
public class Employee {
    private String employeeId;
    private String employeeName;
    private String employeeAddress;
    private String contactNumber;
    private String employeeType;

    public void save() {
       new EmployeeRepository().save(this);
    }

    public void calculateTax() {
       new TaxCalculator().calculateTax(this);
    }

    public String getEmployeeId() {
        return employeeId;
    }

    public void setEmployeeId(String employeeId) {
        this.employeeId = employeeId;
    }

    public String getEmployeeName() {
        return employeeName;
    }

    public void setEmployeeName(String employeeName) {
        this.employeeName = employeeName;
    }

    public String getEmployeeAddress() {
        return employeeAddress;
    }

    public void setEmployeeAddress(String employeeAddress) {
        this.employeeAddress = employeeAddress;
    }

    public String getContactNumber() {
        return contactNumber;
    }

    public void setContactNumber(String contactNumber) {
        this.contactNumber = contactNumber;
    }

    public String getEmployeeType() {
        return employeeType;
    }

    public void setEmployeeType(String employeeType) {
        this.employeeType = employeeType;
    }

}

Außerdem gibt es nur einen Grund, warum Änderungen in der EmployeeRepository-Klasse auftreten können

Grund für die Änderung: Änderung in der Datenbank

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.Statement;

public class EmployeeRepository {

    public void save(Employee employee) {
         String insert = MyUtil.serializeIntoString(employee);
        Connection connection = null;
        Statement statement = null;
        try {
            Class.forName("com.mysql.jdbc.Driver");
            connection = DriverManager.getConnection("jdbc://mysql://localhost:8080/MyDb", "root", "password");
            statement = connection.createStatement();
            statement.execute("insert into employee values ("   insert   ")");

        } catch (Exception e) {
            e.printStackTrace();
        }
}

}

Schließlich gibt es nur einen Grund, warum Änderungen in der TaxCalculator-Klasse auftreten können

Grund für die Änderung: Änderung der Steuerberechnung

public class TaxCalculator {

    public void calculateTax(Employee employee) {
        if (employee.getEmployeeType().equals("fulltime")) {
            // tax calculation for full time employee
        } else if (employee.getEmployeeType().equals("contract")) {
            // tax calculation for contract type employee
        }
    }
}

Hinweis: Alle drei Klassen folgen nun dem Prinzip der Einzelverantwortung und folgen somit beiden Definitionen

Beachten Sie beim Erstellen von Klassen oder Softwarekomponenten Folgendes: Zielen Sie auf eine hohe Kohäsion und lockere Kopplung

Jede Softwarekomponente sollte nur eine und eine Verantwortung haben und
Jede Softwarekomponente sollte einen und nur einen Grund zur Änderung haben