“There should never be more than one reason for a class to change.”

— Robert C. Martin

O co chodzi z SRP?

Zasada jednej odpowiedzialności (SRP) to pierwsza litera z akronimu SOLID – pięciu fundamentalnych zasad programowania obiektowego. SRP mówi:
Każda klasa powinna mieć tylko jeden powód do zmiany.

Innymi słowy: klasa powinna zajmować się tylko jednym aspektem funkcjonalności systemu. Im więcej obowiązków jej przypiszemy, tym trudniej ją zrozumieć, przetestować i utrzymać.

Gdyby widoczny na zdjęciu powyżej scyzoryk to symbol złamania zasady SRP. Na pierwszy rzut oka: praktyczny i wszechstronny. Ale czy naprawdę chcesz, żeby Twoja klasa była jednocześnie nożem, pilnikiem, korkociągiem i śrubokrętem? Taki kod może i działa, ale jest trudny do utrzymania i rozwijania. SRP mówi jasno: jedno narzędzie – jedno zadanie.

Przykład problemu – klasa robiąca wszystko

Załóżmy, że budujemy prosty system obsługi zamówień. Mamy klasę Zamowienie, która:

• przechowuje dane zamówienia,
• oblicza łączną cenę,
• zapisuje dane do pliku.

public class Zamowienie {
    private List<String> produkty;
    private double suma;

    public void dodajProdukt(String produkt, double cena) {
        produkty.add(produkt);
        suma += cena;
    }

    public double pobierzSume() {
        return suma;
    }

    public void zapiszDoPliku(String sciezka) {
        // kod zapisujący zamówienie do pliku
    }
}

Ta klasa łamie SRP – zajmuje się zarówno logiką biznesową, jak i zapisem danych. Jeśli zmieni się sposób zapisu do pliku, musimy modyfikować klasę Zamowienie, choć nie zmieniła się logika zamówienia.

Rozwiązanie – podział odpowiedzialności

Zastosujmy SRP i rozdzielmy odpowiedzialności. Stworzymy osobną klasę do obsługi zapisu zamówień.

public class Zamowienie {
    private List<String> produkty = new ArrayList<>();
    private double suma = 0;

    public void dodajProdukt(String produkt, double cena) {
        produkty.add(produkt);
        suma += cena;
    }

    public double pobierzSume() {
        return suma;
    }

    public List<String> pobierzProdukty() {
        return produkty;
    }
}

public class ZapisZamowienia {
    public void zapiszDoPliku(Zamowienie zamowienie, 
    String sciezka) {
        // kod zapisujący zamówienie do pliku
    }
}

Teraz:

• Zamowienie odpowiada tylko za logikę zamówienia.
• ZapisZamowienia odpowiada tylko za zapis danych.

Jeśli kiedyś zmienimy sposób zapisu (np. z pliku na bazę danych), nie musimy dotykać klasy Zamowienie. Mniej zmian = mniej błędów.

Korzyści z SRP

• Łatwiejsze testowanie – testujesz tylko jedną rzecz naraz.
• Lepsza czytelność – klasy są krótsze i łatwiejsze do zrozumienia.
• Większa elastyczność – możesz zmieniać jedną część systemu bez ryzyka dla innych.
• Lepsze wykorzystanie wzorców projektowych – np. wzorzec Strategy dla różnych sposobów zapisu.

Podsumowanie

Zasada jednej odpowiedzialności to prosty sposób na robienie kodu, który da się utrzymać. Jeśli masz klasę, która „robi wszystko”, to być może nadszedł czas, by ją podzielić. W świecie SOLID mniej znaczy więcej.