SOLID w Javie bez przesady - praktyczne zasady projektowania

Kod może działać poprawnie, a mimo to po kilku miesiącach stać się trudny w rozwijaniu. Właśnie wtedy zasady SOLID w Javie pomagają rozdzielić odpowiedzialności, ograniczyć zależności i bezpieczniej dodawać nowe funkcje. Pokażę, jak każda z pięciu zasad wygląda w praktyce, jakie problemy rozwiązuje i gdzie łatwo przesadzić z jej stosowaniem.

Dlaczego zasady SOLID mają znaczenie w Javie

Dominująca intencja wokół tego tematu jest informacyjno-poradnikowa. Programista nie szuka samego rozwinięcia skrótu, tylko sposobu na rozpoznanie złego projektu i poprawienie go bez przebudowy całej aplikacji.

SOLID to zestaw heurystyk projektowych dla programowania obiektowego. Nie są sztywnym regulaminem ani gwarancją idealnej architektury. Traktuję je raczej jak zestaw pytań kontrolnych, które pomagają ocenić, czy kod będzie odporny na typowe zmiany.

W aplikacji webowej zmianie może ulec sposób zapisu danych, dostawca płatności, format odpowiedzi API albo reguła biznesowa. Jeżeli wszystkie te decyzje są wymieszane w jednej klasie, nawet mała modyfikacja może uruchomić lawinę poprawek. Dobre rozdzielenie odpowiedzialności zmniejsza koszt zmiany, ale nie oznacza automatycznie tworzenia dziesiątek klas.

public class OrderService {
    public void createOrder(Order order) {
        // walidacja zamówienia
        // zapis do bazy
        // wysłanie e-maila
        // naliczenie rabatu
    }
}

Taki kod może być dobrym początkiem prototypu, lecz szybko zaczyna łączyć logikę biznesową, infrastrukturę i komunikację. Zasady SOLID podpowiadają, jak rozdzielić te elementy tak, aby każda część miała jasny cel.

Single Responsibility Principle porządkuje odpowiedzialność

SRP, czyli zasada jednej odpowiedzialności, mówi, że klasa powinna mieć jeden powód do zmiany. Nie chodzi o to, aby zawierała tylko jedną metodę. Chodzi o to, by skupiała się na jednym rodzaju decyzji.

Klasa obsługująca zamówienie nie powinna jednocześnie znać szczegółów zapisu do PostgreSQL, formatowania wiadomości e-mail i obliczania rabatu. Każdy z tych obszarów może zmieniać się niezależnie, więc warto rozdzielić je na osobne komponenty.

public class OrderService {
    private final OrderRepository repository;
    private final DiscountCalculator discountCalculator;
    private final MailSender mailSender;

    public OrderService(
            OrderRepository repository,
            DiscountCalculator discountCalculator,
            MailSender mailSender) {
        this.repository = repository;
        this.discountCalculator = discountCalculator;
        this.mailSender = mailSender;
    }

    public void createOrder(Order order) {
        Money finalPrice = discountCalculator.calculate(order);
        repository.save(order.withPrice(finalPrice));
        mailSender.sendConfirmation(order);
    }
}

Ta klasa nadal koordynuje proces, ale nie wykonuje każdej operacji własnymi rękami. Jedna odpowiedzialność nie oznacza jednej linijki kodu. Oznacza spójny zakres decyzji i zachowania.

Najczęstszy błąd polega na mechanicznym dzieleniu każdej klasy na najmniejsze możliwe fragmenty. Jeżeli powstanie pięć klas, które zawsze zmieniają się razem, projekt wcale nie stał się prostszy. Przy SRP pytam przede wszystkim, kto i dlaczego będzie zmieniał ten kod.

Open/Closed Principle pozwala rozszerzać bez ryzykownej przebudowy

OCP zakłada, że moduł powinien być otwarty na rozszerzanie, ale zamknięty na modyfikację stabilnej części. W praktyce oznacza to projektowanie kodu tak, aby dodanie nowego wariantu nie wymagało dopisywania kolejnych warunków w centralnej metodzie.

Wyobraźmy sobie naliczanie opłat dla kilku metod dostawy. Podejście oparte na instrukcji if działa na początku, ale każda nowa opcja zwiększa ryzyko naruszenia istniejących przypadków.

public interface ShippingCost {
    Money calculate(Order order);
}

public final class CourierShipping implements ShippingCost {
    public Money calculate(Order order) {
        return Money.of(15);
    }
}

public final class ParcelLockerShipping implements ShippingCost {
    public Money calculate(Order order) {
        return Money.of(10);
    }
}

Serwis może teraz przyjąć dowolną implementację ShippingCost. Dodanie dostawy ekspresowej nie wymaga zmiany algorytmu, który już obsługuje kuriera i paczkomat. Nowe zachowanie trafia do nowej klasy, a istniejący kod pozostaje stabilny.

Nie każda zmienność wymaga od razu strategii, fabryki i kilku interfejsów. Jeżeli aplikacja ma tylko jeden wariant i nie ma realnego sygnału, że pojawią się kolejne, nadmiarowa abstrakcja może utrudnić czytanie. OCP najlepiej stosować tam, gdzie rozszerzenia są prawdopodobne i przewidywalne.

Liskov Substitution Principle chroni przed fałszywą polimorfizacją

LSP mówi, że obiekt typu pochodnego powinien móc zastąpić obiekt typu bazowego bez psucia działania programu. To jedna z zasad najczęściej źle rozumianych, bo samo dziedziczenie nie gwarantuje poprawnej zamienności.

Klasycznym przykładem jest prostokąt i kwadrat. Jeśli kod bazowy pozwala niezależnie ustawiać szerokość i wysokość, kwadrat może złamać oczekiwania, ponieważ zmiana jednego wymiaru zmieni oba.

public interface PaymentMethod {
    PaymentResult pay(Money amount);
}

public final class CardPayment implements PaymentMethod {
    public PaymentResult pay(Money amount) {
        return PaymentResult.success();
    }
}

public final class CashOnDelivery implements PaymentMethod {
    public PaymentResult pay(Money amount) {
        return PaymentResult.success();
    }
}

Jeżeli każda metoda płatności spełnia kontrakt pay, kod korzystający z interfejsu nie musi znać szczegółów implementacji. Problem pojawiłby się wtedy, gdy jedna klasa zawsze rzucałaby UnsupportedOperationException albo zwracała wynik o zupełnie innym znaczeniu.

Przy LSP sprawdzam nie tylko sygnaturę metod, ale też warunki wejściowe, rezultat i wyjątki. Implementacja nie powinna wymagać więcej od klienta niż typ bazowy ani obiecywać mniej. Jeżeli dwa obiekty mają zupełnie różne reguły, lepszy może być wspólny, mniejszy interfejs zamiast dziedziczenia.

Interface Segregation Principle zmniejsza liczbę niepotrzebnych zależności

ISP zaleca, aby klient nie był zmuszany do zależności od metod, których nie używa. Duży interfejs często wygląda wygodnie na diagramie, lecz w praktyce wiąże ze sobą odległe części systemu.

public interface UserOperations {
    User findById(long id);
    void save(User user);
    void delete(long id);
    Report generateReport();
    void exportToCsv();
}

Widok profilu prawdopodobnie potrzebuje tylko findById. Zamiast przekazywać mu cały zestaw operacji, można rozdzielić kontrakty według potrzeb klientów.

public interface UserReader {
    User findById(long id);
}

public interface UserWriter {
    void save(User user);
    void delete(long id);
}

public interface ReportGenerator {
    Report generateReport();
}

Takie interfejsy są łatwiejsze do implementowania i testowania. Mock w teście ma mniej metod, a zmiana raportowania nie musi wpływać na kod odpowiedzialny za odczyt użytkownika. Mały interfejs pokazuje prawdziwe potrzeby klienta, zamiast ujawniać cały moduł.

Pułapka jest podobna jak przy SRP. Interfejs z jedną metodą nie zawsze jest lepszy od sensownego kontraktu z trzema metodami. Liczy się spójność zastosowania, nie sama liczba operacji.

Dependency Inversion Principle oddziela logikę od infrastruktury

DIP mówi, że moduły wysokiego poziomu nie powinny zależeć bezpośrednio od szczegółów technicznych. Obie warstwy powinny zależeć od abstrakcji, a szczegóły powinny te abstrakcje implementować.

Serwis zamówień nie musi wiedzieć, czy dane trafiają do PostgreSQL, pliku czy zewnętrznego API. Wystarczy, że zna kontrakt repozytorium.

public interface OrderRepository {
    void save(Order order);
}

public final class OrderService {
    private final OrderRepository repository;

    public OrderService(OrderRepository repository) {
        this.repository = repository;
    }

    public void place(Order order) {
        repository.save(order);
    }
}

W aplikacji produkcyjnej można podać implementację bazodanową, a w teście prostą wersję pamięciową. W Springu podobny układ uzyskuje się często przez wstrzykiwanie zależności konstruktorem, ale sama zasada nie wymaga konkretnego frameworka.

To właśnie DIP zwykle przynosi najbardziej odczuwalną poprawę w testach. Zamiast uruchamiać bazę danych przy każdym teście serwisu, podstawiamy kontrolowaną implementację. Ceną jest większa liczba typów i konstruktorów, dlatego abstrakcję warto wprowadzać tam, gdzie istnieje zmienność, kosztowna infrastruktura albo potrzeba izolowanych testów.

Jak stosować SOLID bez tworzenia architektonicznego labiryntu

Zasady działają najlepiej jako narzędzie do podejmowania decyzji, a nie checklista odhaczana przy każdej klasie. Ja zaczynam od kodu, który sprawia problem: rośnie zbyt szybko, ma wiele warunków, trudno go przetestować albo każda zmiana wymaga dotykania kilku niezwiązanych modułów.

Praktyczny proces może wyglądać tak:

1. Znajdź powód zmiany. Sprawdź, czy klasa reaguje na zmiany biznesowe, techniczne i komunikacyjne naraz.
2. Wydziel stabilny kontrakt. Twórz interfejs dopiero wtedy, gdy opisuje realną granicę odpowiedzialności.
3. Przenieś zmienność do implementacji. Algorytmy, dostawców i formaty trzymaj poza główną logiką procesu.
4. Dodaj test przed większą refaktoryzacją. Test zabezpiecza zachowanie, które chcesz zachować.
5. Oceń koszt abstrakcji. Jeśli nowa warstwa nie ułatwia zmiany, testowania ani czytania kodu, prawdopodobnie jest zbędna.

Nie próbowałbym projektować całego systemu zgodnie z pięcioma zasadami jeszcze przed napisaniem pierwszej funkcji. Wymagania rzadko są na tyle stabilne, by przewidzieć wszystkie granice. Refaktoryzacja oparta na rzeczywistym problemie zwykle daje lepszy rezultat niż abstrakcje tworzone na zapas.

Trzeba też pamiętać, że SOLID nie zastępuje dobrego modelu domeny, testów ani prostego nazewnictwa. Można mieć kod pełen interfejsów, który nadal miesza odpowiedzialności. Najważniejszy efekt to nie liczba klas, lecz łatwość odpowiedzi na pytanie, gdzie wprowadzić konkretną zmianę.

Co sprawdzić w projekcie Java przed kolejną funkcją

Przed dodaniem większej funkcji przejrzyj klasę, która ma ją obsługiwać. Jeżeli odpowiada za walidację, zapis, komunikację i obliczenia, zacznij od rozdzielenia decyzji, które mają różne przyczyny zmian.

Jeśli dodanie nowego wariantu wymaga modyfikacji wielu instrukcji warunkowych, rozważ polimorfizm lub strategię. Gdy implementacja interfejsu ignoruje część metod, zmniejsz kontrakt. Jeżeli test wymaga bazy danych, sieci i konfiguracji całej aplikacji, poszukaj zależności, którą można odwrócić.

Najzdrowszy projekt nie jest „w stu procentach SOLID”. Jest czytelny, testowalny i gotowy na prawdopodobne zmiany. Właśnie ten praktyczny kompromis odróżnia użyteczne zasady projektowe od architektonicznej mody.