W dobrze zaprojektowanym kodzie jedna klasa nie powinna jednocześnie liczyć cen, formatować danych i wysyłać powiadomień. Zasada SRP, czyli single responsibility principle, porządkuje to bardzo praktycznie: jedna odpowiedzialność, jeden powód do zmiany. Dzięki temu łatwiej testować kod, szybciej go rozumieć i rzadziej psuć coś przy pozornie małej poprawce.
Najkrótsza wersja dla zabieganych
- SRP nie mówi, że klasa ma robić mało, tylko że ma mieć jeden powód do zmiany.
- Jeśli w jednym miejscu mieszają się logika biznesowa, formatowanie i zapis do bazy, odpowiedzialności są sklejone.
- Najlepszy test jest prosty: gdy poprawka w jednym obszarze wymaga dotykania kilku niespokrewnionych fragmentów klasy, projekt jest zbyt ciężki.
- Zasada działa najlepiej razem z małymi, nazwanymi klasami i czytelnymi interfejsami, a nie z przypadkowym rozbijaniem kodu na mikropaczki.
- Przesadna fragmentacja też szkodzi, bo utrudnia śledzenie przepływu i zwiększa liczbę połączeń między klasami.
Co naprawdę oznacza jedna odpowiedzialność
W praktyce SRP sprowadza się do jednego pytania: czy ta klasa zmienia się z jednego powodu, czy z kilku niezależnych? Jeśli w jednym miejscu trzymasz walidację zamówienia, liczenie rabatu, zapis do bazy i wysyłkę maila, to każda z tych zmian zaczyna ciągnąć za sobą pozostałe. Wtedy poprawka przestaje być lokalna, a kod staje się mniej przewidywalny.
Najważniejsze jest tu słowo powód do zmiany. Klasa może mieć kilka metod i nadal dobrze spełniać SRP, jeśli wszystkie wspierają ten sam cel. Z drugiej strony nawet krótka klasa może łamać zasadę, gdy miesza logikę domenową z formatowaniem, integracją z API i zapisem danych.
To rozróżnienie wygląda subtelnie, ale w praktyce oszczędza mnóstwo czasu przy refaktoryzacji, testach i code review. Gdy już je opanujesz, dużo łatwiej zauważysz, gdzie kod zaczyna robić za dużo naraz.
Jak rozpoznać przeciążoną klasę
Najprostszym sygnałem jest to, że jedna zmiana wymaga ruszenia kilku niezwiązanych fragmentów klasy. Ja zwykle patrzę wtedy nie na długość pliku, tylko na to, ile różnych „światów” spotyka się w jednym miejscu.
| Objaw | Co zwykle oznacza | Na co zwrócić uwagę |
|---|---|---|
| Zmiana wyglądu raportu wymaga edycji logiki liczenia | Format i domena są sklejone | Czy można oddzielić liczenie od prezentacji |
| Test jednostkowy potrzebuje bazy, mailera i parsera | Klasa zależy od zbyt wielu rzeczy naraz | Czy da się wyizolować element, który faktycznie testujesz |
| Nazwa brzmi jak Manager, Helper albo Service i robi wszystko | Zakres odpowiedzialności jest rozmyty | Czy da się nazwać klasę bardziej konkretnie |
Metody mają niepowiązane tematy: validate, save, send, export
|
Mieszają się różne odpowiedzialności | Czy każda metoda obsługuje ten sam cel, czy tylko korzysta z tego samego pliku |
Jeśli widzę dwa lub więcej takich sygnałów, zakładam, że odpowiedzialności trzeba rozdzielić. Nie robię tego jednak automatycznie, bo czasem problem leży w nazwie albo w złym umiejscowieniu logiki, a nie w samej liczbie klas. Gdy symptomy są już widoczne, naturalnym następnym krokiem jest prosty przykład refaktoryzacji.
Jak rozdzielić odpowiedzialności na prostym przykładzie
Najczytelniej widać to na zamówieniu. Wyobraź sobie klasę OrderService, która jednocześnie liczy cenę, zapisuje dane, wysyła potwierdzenie i jeszcze loguje zdarzenie analityczne. Taki kod działa, dopóki nie trzeba zmienić tylko jednego z tych kroków.
| Wcześniej | Po podziale | Dlaczego to działa lepiej |
|---|---|---|
OrderService liczy cenę i rabaty |
OrderPricing |
Zmiany promocji nie dotykają zapisu ani komunikacji |
OrderService zapisuje dane |
OrderRepository |
Zmiana bazy lub ORM nie wpływa na reguły biznesowe |
OrderService wysyła potwierdzenie |
OrderNotifier |
Można zmienić kanał kontaktu bez ruszania domeny |
OrderService orkiestruje cały proces |
PlaceOrderUseCase |
Warstwa nadrzędna pozostaje cienka i czytelna |
Ja zwykle zaczynam od pytania, co w tej klasie zmienia się z innego powodu niż reszta. Jeśli odpowiedzi są różne, to znak, że mamy kilka odpowiedzialności, nawet jeśli wszystko jeszcze mieści się w jednym pliku. To nie jest dzielenie dla samego dzielenia, tylko usuwanie wspólnego miejsca, które niepotrzebnie scala niezależne zmiany.
Czego ta zasada nie oznacza
SRP bywa źle rozumiane, więc warto od razu odsiać kilka mitów. Najczęstszy błąd to traktowanie tej zasady jak nakazu minimalizmu za wszelką cenę.
- Nie oznacza, że klasa ma mieć jedną metodę.
- Nie oznacza, że każda funkcja musi trafić do osobnego pliku.
- Nie oznacza, że kod trzeba rozbijać nawet wtedy, gdy wszystko zmienia się z tego samego powodu.
- Nie oznacza też, że rozmiar klasy sam w sobie jest problemem.
Klasa może być duża i nadal spełniać SRP, jeśli wszystkie jej elementy służą jednemu celowi. Z kolei mała klasa może łamać zasadę, gdy miesza dwa różne światy, na przykład reguły cenowe i wysyłkę e-maili. W praktyce chodzi o spójność, a nie o sztucznie niską liczbę linii.
To ważne rozróżnienie, bo bez niego łatwo wpaść w drugą skrajność i zacząć produkować kod, który jest „ładnie rozdzielony”, ale trudny do zrozumienia. A skoro wiesz już, czego SRP nie oznacza, zostaje pytanie, kiedy warto pilnować jej bardzo rygorystycznie.
Kiedy warto ją stosować, a kiedy lepiej zwolnić
SRP najbardziej pomaga tam, gdzie zmiany pojawiają się często i z różnych stron. W systemach biznesowych, integracjach z zewnętrznymi usługami, raportowaniu i przetwarzaniu danych koszt pomyłki rośnie szybko, więc rozdzielenie odpowiedzialności daje realny zwrot.
| Sytuacja | Jak podchodzę do SRP | Dlaczego |
|---|---|---|
| Moduł biznesowy, który często się zmienia | Pilnuję SRP mocno | Zmiany mają wysoki koszt uboczny |
| Integracja z API, faktury, raporty | Rozdzielam odpowiedzialności wcześnie | Każdy obszar zmienia się z innego powodu |
| Mały skrypt jednorazowy | Nie rozdrabniam bez potrzeby | Prostota zwykle wygrywa z nadprojektem |
| Prototyp albo proof of concept | Trzymam prostszy układ, dopóki nie znam kierunku zmian | Za wczesna abstrakcja może spowolnić pracę |
Właśnie tu pojawia się kompromis: SRP ma zmniejszać koszt przyszłych zmian, a nie poprawiać wygląd architektury na papierze. Jeśli wydzielenie kolejnej klasy dokłada tylko nazwy i pliki, ale nie redukuje ryzyka, efekt bywa słabszy niż oczekiwany. Dlatego wolę stosować zasadę tam, gdzie rzeczywiście stabilizuje kod, a nie tam, gdzie tylko wygląda elegancko.
Gdy już wiem, że warto coś rozdzielić, przechodzę do prostej, powtarzalnej kontroli przed code review.
Co sprawdzam przed code review, żeby nie rozbić kodu za bardzo
Najbardziej praktyczne pytanie brzmi: czy po zmianie kod będzie łatwiejszy w utrzymaniu, czy tylko bardziej rozproszony? Żeby to ocenić szybko, zwykle sprawdzam kilka rzeczy.
- Czy mogę opisać klasę jednym zdaniem bez wyliczania trzech różnych zadań?
- Czy zmiana formatu, bazy albo kanału wysyłki powinna dotknąć tej samej klasy?
- Czy testy dla jednej funkcji wymagają przygotowania rzeczy niezwiązanych z jej zadaniem?
- Czy nazwa klasy mówi o jednym celu, czy o zbiorze przypadkowych czynności?
- Czy po wydzieleniu nowej klasy interfejs staje się prostszy, czy tylko bardziej rozproszony?
Jeśli na dwa z tych pytań odpowiadam „tak”, zwykle mam już dość danych, żeby wydzielić odpowiedzialność. Jeżeli po refaktoryzacji kod staje się czytelniejszy, testy prostsze, a jedna poprawka obejmuje mniejszy obszar, to znak, że ruch był dobry. I właśnie taki efekt powinna dawać SRP: mniej zaskoczeń przy każdej kolejnej zmianie.
