SOLID OOP w praktyce - Jak uporządkować kod obiektowy?

W dobrze utrzymywanym kodzie obiektowym nie chodzi o to, żeby klas było jak najwięcej, tylko żeby każda miała jasny zakres odpowiedzialności i nie wymuszała kosztownych zmian przy każdej nowej funkcji. Ten artykuł pokazuje, jak zasady SOLID przekładają się na codzienne decyzje projektowe, kiedy pomagają najbardziej, jak stosować je w aplikacjach webowych i gdzie łatwo przesadzić. W praktyce to właśnie ten zestaw reguł porządkuje solid oop bez zamieniania projektu w architektoniczny labirynt.

Czym jest SOLID i kiedy naprawdę się przydaje

SOLID to pięć zasad projektowania, które pomagają ograniczyć chaos w klasach, interfejsach i zależnościach. Najkrócej: każda reguła podpowiada, jak pisać kod tak, żeby łatwiej go było rozwijać, testować i wymieniać fragmentami, kiedy zmienia się wymaganie biznesowe.

Ja traktuję te zasady nie jak dogmat, ale jak filtr. Jeśli klasa zaczyna pełnić kilka ról naraz, jeśli zmiana jednego szczegółu pociąga za sobą serię poprawek albo jeśli testy wymagają wielu obejść, to zwykle jest to sygnał, że architektura potrzebuje korekty. W aplikacjach webowych widać to szczególnie szybko: w obsłudze płatności, wysyłce powiadomień, integracjach z API i logice zamówień.

• SRP pilnuje, żeby jedna klasa miała jedną odpowiedzialność.
• OCP ułatwia dodawanie nowych zachowań bez ciągłego ruszania starego kodu.
• LSP sprawdza, czy podtyp naprawdę zachowuje się jak obiekt bazowy.
• ISP chroni przed zbyt grubymi interfejsami.
• DIP zmniejsza zależność logiki biznesowej od konkretów infrastruktury.

To nie jest zestaw zasad do odhaczania przy każdym pliku. Najwięcej daje tam, gdzie kod żyje długo i często się zmienia, a mniej tam, gdzie piszesz krótki skrypt lub jednorazowy prototyp. Gdy już to rozumiesz, można przejść do samych zasad i zobaczyć, co naprawdę poprawiają w klasach.

Trzy zasady, które porządkują odpowiedzialność klasy

Tu najczęściej robi się największą różnicę. Jeśli klasa ma robić wszystko, to po kilku miesiącach zaczyna być zlepkiem reguł biznesowych, walidacji, logiki prezentacji i wywołań do bazy. Ja zwykle zaczynam właśnie od tych trzech zasad, bo one dają najszybszy zwrot w czytelności kodu.

SRP, czyli jedna odpowiedzialność

Single Responsibility Principle mówi w praktyce tyle: klasa powinna mieć jeden powód do zmiany. Jeśli w jednym serwisie obsługujesz rejestrację użytkownika, wysyłkę maila, zapis audytu i jeszcze budowanie odpowiedzi HTTP, to nie masz jednego elementu, tylko mały magazyn obowiązków.

W aplikacji webowej dobry przykład to UserRegistrationService, który przyjmuje dane, tworzy konto i deleguje wysyłkę potwierdzenia do osobnego komponentu EmailSender. Dzięki temu zmiana treści maila nie dotyka logiki rejestracji, a zmiana walidacji hasła nie rusza mechanizmu powiadomień. Najważniejszy zysk jest prosty: mniej zależności, krótsze testy i mniejsza szansa, że poprawka w jednym miejscu popsuje coś zupełnie obok.

Typowy błąd początkujących polega na tym, że mylą jedną odpowiedzialność z jedną metodą albo jedną klasą dla jednego bytu domenowego. To nie o to chodzi. Jedna odpowiedzialność to jeden powód do zmiany, a nie magiczna liczba metod w pliku. Gdy ta zasada zaczyna działać, naturalnie prowadzi do pytania, jak rozszerzać zachowanie bez rozbijania istniejących klas.

OCP, czyli rozszerzanie bez ciągłego grzebania w środku

Open-Closed Principle jest użyteczne wtedy, gdy przewidujesz nowe warianty zachowania. Jeśli w CheckoutService masz długi łańcuch if lub switch po typach rabatów, metodach płatności albo źródłach wysyłki, to każdy nowy wariant zmusza cię do edycji centralnej klasy. W praktyce to właśnie tam rośnie koszt zmian.

Lepszy kierunek to wydzielenie strategii albo osobnych implementacji, które wspólna część systemu tylko wybiera. Dodanie nowego rabatu nie wymaga wtedy przepisywania starej logiki, tylko dopięcia nowej klasy zgodnej z kontraktem. To działa dobrze w panelach administracyjnych, systemach promocji, integracjach z bramkami płatności i wszędzie tam, gdzie wariantów przybywa szybciej niż czasu na refaktor.

Uważam jednak, że OCP bywa źle rozumiane. Nie oznacza zakazu zmian w starym kodzie. Czasem najpierw trzeba uprościć model, usunąć niepotrzebne zależności albo nawet rozbić jedną klasę, zanim rozszerzanie zacznie mieć sens. Dopiero po takim porządku kolejne rozszerzenia stają się naprawdę tanie.

LSP, czyli podtyp nie może zaskakiwać

Liskov Substitution Principle sprawdza, czy obiekt potomny da się wstawić wszędzie tam, gdzie oczekiwany jest obiekt bazowy, bez psucia logiki. Jeśli PremiumUser dziedziczy po User, ale przy wywołaniu pewnej metody zwraca wyjątek, bo „w jego przypadku to nie działa”, to kontrakt został złamany.

To ważne zwłaszcza wtedy, gdy używasz dziedziczenia do modelowania zachowań biznesowych. Dziedziczenie jest wygodne, ale ma ukryty koszt: zakłada, że potomny obiekt naprawdę spełnia oczekiwania klasy bazowej. Gdy tak nie jest, kod staje się kruchy, a testy zaczynają wymagać wyjątków i obejść. W praktyce wolę wtedy wrócić do kompozycji, bo często daje większą swobodę niż sztuczne dopasowywanie potomka do bazowego kontraktu.

Jeśli po tych trzech zasadach masz już bardziej przewidywalne klasy, kolejny krok to ograniczenie sprzężenia między nimi. I właśnie na tym opierają się dwie następne reguły.

Dwie zasady, które zmniejszają sprzężenie

Jeśli poprzednia trójka porządkuje wnętrze klasy, to ta dwójka pilnuje granic między klasami. Tu najczęściej wygrywa kod, który łatwo podmienić w testach i w produkcji, bez grzebania w logice biznesowej.

ISP, czyli interfejs ma być mały i konkretny

Interface Segregation Principle mówi, że lepiej mieć kilka małych interfejsów niż jeden wielki, który zmusza implementacje do dostarczania metod, z których nigdy nie skorzystają. Jeśli tworzysz interfejs NotificationChannel z metodami do maila, SMS-a, pushy i webhooków, część klas będzie implementować tylko połowę z nich, a resztę zostawiać pustą albo „na wszelki wypadek”.

W praktyce lepiej rozdzielić to na mniejsze kontrakty, na przykład EmailNotifier i SmsNotifier, jeśli różnią się nie tylko nazwą, ale też użyciem i zależnościami. Dzięki temu implementacja nie udaje, że obsługuje coś, czego naprawdę nie obsługuje. Z punktu widzenia utrzymania to duża sprawa, bo mniejsze interfejsy są prostsze do testowania i trudniej je przypadkiem złamać.

Przeczytaj również: Wzorzec szablonowa metoda – kiedy upraszcza kod, a kiedy szkodzi?

DIP, czyli logika biznesowa nie powinna znać konkretów infrastruktury

Dependency Inversion Principle działa najlepiej tam, gdzie domena zaczyna zbyt mocno zależeć od zewnętrznych bibliotek i usług. Jeśli OrderService tworzy sobie bezpośrednio klienta Stripe, zapisuje dane do konkretnej bazy i sam wysyła maila, to testowanie i wymiana któregokolwiek elementu stają się niepotrzebnie trudne.

Lepszy model jest prostszy: logika biznesowa zależy od abstrakcji, a konkretna implementacja jest dostarczana z zewnątrz, zwykle przez wstrzykiwanie zależności. Wtedy PaymentGateway może mieć implementację Stripe dziś, a innego dostawcę jutro, bez przepisywania całej usługi zamówienia. To właśnie jest praktyczna wartość DIP: mniej twardych połączeń między warstwami i więcej swobody przy zmianie dostawcy, frameworka albo sposobu integracji.

Kiedy te dwie zasady zaczynają działać razem, projekt robi się wyraźnie bardziej elastyczny. Następny krok to przełożenie ich na codzienną pracę, a nie tylko na ładne definicje.

Jak wdrażać SOLID w projekcie webowym krok po kroku

W projekcie, który już istnieje, nie zaczynam od przepisywania wszystkiego. Zaczynam od miejsc, gdzie zmiana boli najbardziej: od klas z największą liczbą zależności, od długich instrukcji warunkowych i od testów, które wymagają zbyt wielu mocków. To tam zasady SOLID dają najszybszy efekt.

Praktyczna kolejność zwykle wygląda tak:

1. Znajdź klasę, która ma kilka powodów do zmiany.
2. Oddziel logikę biznesową od integracji technicznych.
3. Zamień switch i duże if na polimorfizm albo strategię, jeśli wariantów jest więcej niż 2-3.
4. Sprawdź, czy obiekty potomne naprawdę spełniają kontrakt bazowy.
5. Dopiero potem dodawaj kolejne abstrakcje, jeśli nadal upraszczają kod.

W aplikacjach webowych taka sekwencja działa lepiej niż wielka refaktoryzacja na start. Jeśli najpierw uporządkujesz odpowiedzialność, a dopiero potem zależności, unikniesz sytuacji, w której tworzysz abstrakcje tylko po to, by „mieć SOLID”, bez realnego zysku dla projektu. To prowadzi wprost do najczęstszych błędów, które widzę w praktyce.

Najczęstsze błędy i miejsca, w których zasady zaczynają przeszkadzać

SOLID działa dobrze, ale tylko wtedy, gdy używasz go z rozsądkiem. Przesada bywa równie kosztowna jak brak architektury, a w prostych projektach nadmiar wzorców potrafi zamienić czytelny kod w zbiór warstw, których nikt nie chce dotykać.

• Tworzenie interfejsu do wszystkiego - nie każda klasa potrzebuje własnego kontraktu. Czasem to tylko szum, nie architektura.
• Mylenie OCP z zakazem edycji - dobre rozszerzalne rozwiązanie czasem wymaga wcześniejszego uproszczenia starego kodu.
• Dziedziczenie tam, gdzie lepsza jest kompozycja - szczególnie gdy potomne klasy nie spełniają już naturalnie kontraktu bazowego.
• Rozbijanie prostego CRUD-a na dziesięć warstw - jeśli funkcjonalność jest mała, prostota może wygrać z elegancką architekturą.
• Projektowanie pod hipotetyczne przyszłe wymagania - abstrakcje tworzone „na wszelki wypadek” często nigdy nie zwracają kosztu.

Najbardziej praktyczna zasada, jaką sam stosuję, jest prosta: jeśli zmiana w jednej klasie zaczyna pociągać za sobą inne, przyjrzyj się granicom odpowiedzialności. Jeśli natomiast kod jest mały, przewidywalny i nie będzie żył długo, nie dokładaj mu architektonicznego ciężaru tylko dlatego, że tak wygląda „czysta” teoria. Taki realizm oszczędza czas i nerwy, a jednocześnie nie odbiera korzyści tam, gdzie są naprawdę potrzebne.

Co zostaje do zastosowania przy następnym refaktorze

• Najpierw patrzę na odpowiedzialność klasy, potem na wzorce i dopiero na nazwy typu „manager” czy „service”.
• Jeśli zmiana wymaga edycji kilku plików naraz, szukam miejsca, w którym da się przeciąć zależność.
• Interfejs ma chronić przed zmianą i ułatwiać testy, a nie mnożyć pliki dla samej zasady.
• Dziedziczenie stosuję ostrożnie; przy złożonych zależnościach bardzo często lepiej działa kompozycja.

Jeśli mam wskazać jeden praktyczny wniosek, to taki: zacznij od klasy, która robi najwięcej rzeczy naraz, i rozbijaj ją tylko tam, gdzie faktycznie poprawia to czytelność, testy i rozwój funkcji. Właśnie tak SOLID przestaje być hasłem, a staje się narzędziem, które realnie upraszcza pracę nad kodem obiektowym.