Single Responsibility Principle

Trochę teorii

Pierwszą z zasad kryjących się pod literą S jest tytułowe Single Responsibility Principle czyli zasada jednej odpowiedzialności. Jej definicję można przedstawić następująco:

Przykładowy kod

Ponieważ definicja ta jest wystarczająco prosta zatem pokażę teraz jak łatwo tę zasadę złamać, oraz jak powinno się tego w konkretnej sytuacji uniknąć. Przykładem jest klasa Report, która obsługuje funkcje związane z raportowaniem jakichś danych z systemu.

public class Report {
    private String reportData1, reportData2;
    private String completeReport;

    public Report(String reportData1, String reportData2) {
        this.reportData1 = reportData1;
        this.reportData2 = reportData2;
    }

    public void generateReport(){
        completeReport = reportData1 + reportData2;
    }
    public void printReport(){
        System.out.println(completeReport);
    }
}

Zauważmy że klasa ta ma na celu połączenie dwóch pół z danymi w celu stworzenia raportu oraz jego wydrukowania. I tu pojawia się sedno problemu, a więc złamanie zasady. Oprócz generowania raportu klasa również odpowiada za jego drukowanie. Aby implementacja była zgodna z zasadą jednej odpowiedzialności kod powinien wyglądać następująco:

public class Report {
    private String reportData1, reportData2;
    private String completeReport;

    public Report(String reportData1, String reportData2) {
        this.reportData1 = reportData1;
        this.reportData2 = reportData2;
    }

    public String getCompleteReport() {
        return completeReport;
    }

    public void generateReport(){
        completeReport = reportData1 + reportData2;
    }
}

public class Printer {
    public String textToPrint;

    public Printer(String textToPrint) {
        this.textToPrint = textToPrint;
    }

    public void printReport() {
        System.out.println(textToPrint);
    }
}

Wydzieliliśmy z klasy Report nową klasę Printer, której zasadą jest tylko drukowanie raportu. Pamiętajmy, że wypisanie tekstu do konsoli jest tylko przykładem. Rzeczywista implementacja drukowania z pewnością byłaby bardziej skomplikowana.

Podsumowanie

Stosowanie zasady jednej odpowiedzialności wydaje się być dosyć proste i oczywiste, lecz w praktyce często wydaje nam się że zaoszczędzimy czas łącząc różne odpowiedzialności w jedną klasę bądź metodę. Jednak po pewnym czasie może okazać się, że funkcjonalność klasy powinna być wykorzystana w innym miejscu. Wtedy będziemy musieli refaktoryzować klasę i wydzielać z niej wybraną funkcjonalność.