Wzorce projektowe w Javie — 23 wzorce GoF z przykładami w nowoczesnej Javie

Wzorce projektowe w Javie to sprawdzone, nazwane schematy rozwiązywania powtarzalnych problemów w kodzie obiektowym — od tworzenia obiektów, przez łączenie klas, po komunikację między nimi. Najbardziej znany katalog, opisany w 1994 r. przez tzw. Gang of Four (GoF), obejmuje 23 wzorce podzielone na kreacyjne, strukturalne i behawioralne.

Znajomość wzorców daje dwie rzeczy: gotowe rozwiązania dla typowych problemów oraz wspólny język w zespole. Gdy ktoś mówi „tu wystarczy strategia”, wszyscy wiedzą, o jaki układ klas chodzi. Poniżej znajdziesz przegląd wszystkich grup, przykłady z JDK oraz najważniejsze wzorce zaimplementowane w nowoczesnej Javie (21 i nowszej).

Trzy grupy wzorców projektowych

Nie musisz znać wszystkich 23 wzorców na pamięć. W codziennej pracy z Javą najczęściej spotkasz kilkanaście z nich — omawiam je poniżej.

Wzorce kreacyjne w Javie

Singleton

Singleton gwarantuje istnienie dokładnie jednej instancji klasy i daje do niej globalny dostęp. W Javie najprostszą i bezpieczną (również przy serializacji i refleksji) implementacją jest enum — co zalecał już Joshua Bloch w „Effective Java”:

public enum Konfiguracja {
    INSTANCJA;

    private final Properties wlasciwosci = new Properties();

    public String pobierz(String klucz) {
        return wlasciwosci.getProperty(klucz);
    }
}

// użycie
String url = Konfiguracja.INSTANCJA.pobierz("db.url");

Jeśli potrzebujesz leniwej inicjalizacji w zwykłej klasie, użyj idiomu „holder” — JVM gwarantuje, że klasa wewnętrzna zostanie załadowana dopiero przy pierwszym wywołaniu i w sposób bezpieczny wątkowo:

public final class Rejestr {
    private Rejestr() {}

    private static final class Holder {
        static final Rejestr INSTANCJA = new Rejestr();
    }

    public static Rejestr getInstance() {
        return Holder.INSTANCJA;
    }
}

W aplikacjach Spring Boot rzadko piszesz Singletona ręcznie — beany mają domyślnie zasięg singleton, a kontener sam pilnuje jednej instancji.

Budowniczy (Builder)

Builder pozwala tworzyć obiekty o wielu, często opcjonalnych parametrach bez konstruktorów z dziesięcioma argumentami. W JDK używasz go na co dzień, np. przy HttpClient.newBuilder() czy StringBuilder.

public final class Zamowienie {
    private final String klient;
    private final List<String> produkty;
    private final boolean ekspres;

    private Zamowienie(Builder b) {
        this.klient = b.klient;
        this.produkty = List.copyOf(b.produkty);
        this.ekspres = b.ekspres;
    }

    public static Builder builder(String klient) {
        return new Builder(klient);
    }

    public static final class Builder {
        private final String klient;
        private final List<String> produkty = new ArrayList<>();
        private boolean ekspres;

        private Builder(String klient) {
            this.klient = Objects.requireNonNull(klient);
        }

        public Builder produkt(String nazwa) { produkty.add(nazwa); return this; }
        public Builder ekspres(boolean wartosc) { this.ekspres = wartosc; return this; }

        public Zamowienie build() {
            if (produkty.isEmpty()) {
                throw new IllegalStateException("Zamówienie musi mieć co najmniej jeden produkt");
            }
            return new Zamowienie(this);
        }
    }
}

// użycie
Zamowienie z = Zamowienie.builder("Jan Kowalski")
        .produkt("Klawiatura")
        .produkt("Mysz")
        .ekspres(true)
        .build();

Zaletą jest walidacja w jednym miejscu (build()) i niemutowalny obiekt wynikowy. W projektach z Lombokiem ten sam efekt daje adnotacja @Builder.

Metoda wytwórcza i fabryka

Metoda wytwórcza ukrywa przed klientem, jaka konkretna klasa zostanie utworzona. W nowoczesnej Javie dobrze łączy się z interfejsami zapieczętowanymi (sealed), dzięki którym kompilator zna pełną listę implementacji:

public sealed interface Powiadomienie permits Email, Sms {
    void wyslij(String tresc);

    static Powiadomienie utworz(String kanal) {
        return switch (kanal) {
            case "email" -> new Email();
            case "sms" -> new Sms();
            default -> throw new IllegalArgumentException("Nieznany kanał: " + kanal);
        };
    }
}

final class Email implements Powiadomienie {
    public void wyslij(String tresc) { /* wysyłka e-mail */ }
}

final class Sms implements Powiadomienie {
    public void wyslij(String tresc) { /* wysyłka SMS */ }
}

Fabryka abstrakcyjna idzie krok dalej: tworzy całe rodziny powiązanych obiektów, np. komplet komponentów interfejsu dla jasnego i ciemnego motywu. Prototyp (kopiowanie istniejących obiektów) jest w Javie rzadziej używany — zamiast clone() zwykle lepiej sprawdza się konstruktor kopiujący.

Wzorce strukturalne w Javie

Adapter i Dekorator na przykładzie java.io

Najlepszą lekcją obu wzorców jest jedna linijka z biblioteki standardowej:

try (var reader = new BufferedReader(
        new InputStreamReader(new FileInputStream("dane.txt"), StandardCharsets.UTF_8))) {
    reader.lines().forEach(System.out::println);
}

InputStreamReader to adapter — dostosowuje strumień bajtów (InputStream) do interfejsu strumienia znaków (Reader). BufferedReader to dekorator — opakowuje dowolny Reader i dodaje buforowanie oraz metodę lines(), nie zmieniając interfejsu bazowego. Dekoratory można nakładać warstwowo, co daje elastyczność bez mnożenia podklas.

Fasada

Fasada udostępnia prosty interfejs do złożonego podsystemu. Klasycznym przykładem w świecie Javy jest SLF4J (Simple Logging Facade for Java): Twój kod woła logger.info(), a fasada przekazuje to do Logbacka, Log4j 2 czy java.util.logging. Ten sam wzorzec na przykładzie PHP opisujemy w artykule Fasada — wzorzec projektowy.

Pełnomocnik (Proxy)

Proxy ma ten sam interfejs co obiekt docelowy i kontroluje dostęp do niego. To fundament Springa: adnotacje @Transactional, @Cacheable czy @Async działają dzięki temu, że kontener wstrzykuje proxy, które przed i po wywołaniu Twojej metody otwiera transakcję, sprawdza cache lub przenosi wykonanie do innego wątku. Wynika z tego znana pułapka: wywołanie metody @Transactional z innej metody tej samej klasy omija proxy, więc transakcja nie zostanie utworzona.

Kompozyt, Most i Pyłek

• Kompozyt — pozwala traktować pojedynczy obiekt i grupę obiektów jednakowo, np. plik i katalog w drzewie systemu plików albo komponent i kontener w interfejsie graficznym.
• Most — oddziela abstrakcję od implementacji, żeby mogły zmieniać się niezależnie. Przykładem jest JDBC: Twój kod używa interfejsów Connection i Statement, a sterownik konkretnej bazy dostarcza implementację.
• Pyłek (Flyweight) — współdzieli niezmienne obiekty, by oszczędzać pamięć. Integer.valueOf() zwraca obiekty z pamięci podręcznej dla wartości od -128 do 127, dlatego porównywanie obiektów Integer operatorem == „czasem działa”, a czasem nie.

Wzorce behawioralne w Javie

Strategia

Strategia pozwala wymieniać algorytm w trakcie działania programu. Od Javy 8 strategia to zwykle po prostu lambda lub referencja do metody — najlepszym przykładem jest Comparator:

List<Produkt> produkty = pobierzProdukty();

Comparator<Produkt> poCenie = Comparator.comparing(Produkt::cena);
Comparator<Produkt> poNazwie = Comparator.comparing(Produkt::nazwa);

produkty.sort(sortujPoCenie ? poCenie : poNazwie.reversed());

Sam algorytm sortowania się nie zmienia — List.sort() dla obiektów używa TimSorta o złożoności O(n log n) — wymieniasz tylko sposób porównywania elementów. Jak na tym tle wypadają inne metody, pokazuje zestawienie złożoności obliczeniowej algorytmów sortowania.

Dla własnej logiki wystarczy interfejs funkcyjny, np. UnaryOperator<BigDecimal> dla różnych sposobów naliczania rabatu. Nie trzeba tworzyć osobnej klasy dla każdego wariantu, o ile logika jest krótka.

Obserwator

Obserwator powiadamia zarejestrowanych odbiorców o zmianie stanu. Klasy java.util.Observer i Observable są przestarzałe od Javy 9, więc w nowym kodzie użyj własnej listy słuchaczy, PropertyChangeListener, mechanizmu zdarzeń Springa (ApplicationEventPublisher) albo bibliotek reaktywnych.

public class Magazyn {
    private final List<Consumer<String>> sluchacze = new CopyOnWriteArrayList<>();

    public void subskrybuj(Consumer<String> sluchacz) {
        sluchacze.add(sluchacz);
    }

    public void produktDostepny(String nazwa) {
        sluchacze.forEach(s -> s.accept(nazwa));
    }
}

// użycie
magazyn.subskrybuj(nazwa -> System.out.println("Wyślij e-mail: dostępny " + nazwa));

CopyOnWriteArrayList pozwala bezpiecznie dodawać słuchaczy z innych wątków w trakcie powiadamiania.

Metoda szablonowa i Łańcuch zobowiązań

Metoda szablonowa definiuje szkielet algorytmu w klasie bazowej, a podklasy uzupełniają wybrane kroki. Tak działa np. AbstractList — implementujesz get() i size(), a resztę metod listy dostajesz gratis.

Łańcuch zobowiązań przekazuje żądanie przez kolejne obiekty, z których każdy może je obsłużyć lub przekazać dalej. To zasada działania filtrów serwletów, łańcucha filtrów Spring Security i ogólnie middleware w aplikacjach webowych.

Odwiedzający a sealed i dopasowanie wzorców

Odwiedzający (Visitor) służy do dodawania operacji na hierarchii klas bez modyfikowania tych klas. Jest jednak rozbudowany i trudny do czytania. Od Javy 21 w wielu przypadkach prościej użyć zapieczętowanej hierarchii i switch z dopasowaniem wzorców rekordów — kompilator sam sprawdzi, czy obsłużyłeś wszystkie przypadki:

sealed interface Ksztalt permits Kolo, Prostokat {}
record Kolo(double r) implements Ksztalt {}
record Prostokat(double a, double b) implements Ksztalt {}

static double pole(Ksztalt k) {
    return switch (k) {
        case Kolo(double r) -> Math.PI * r * r;
        case Prostokat(double a, double b) -> a * b;
    };
}

Pozostałe wzorce behawioralne to Polecenie (żądanie jako obiekt, w Javie często Runnable lub lambda), Iterator (Iterator i pętla for-each), Stan (zachowanie zależne od stanu obiektu, w Javie często enum z metodami), Mediator, Pamiątka (zapis i odtwarzanie stanu, np. do funkcji „cofnij”) oraz Interpreter (np. java.util.regex.Pattern).

Kiedy stosować wzorce projektowe, a kiedy nie

Wzorce są narzędziem, a nie celem. Kilka praktycznych zasad:

1. Zaczynaj od najprostszego kodu. Wzorzec wprowadzaj, gdy pojawia się problem, który rozwiązuje — np. trzeci if wybierający algorytm to dobry moment na strategię.
2. Sprawdź, czy język lub framework nie robi tego za Ciebie. Lambdy, rekordy, enumy i kontener Springa eliminują sporo klasycznego kodu wzorców.
3. Nie nadużywaj Singletona. Globalny stan utrudnia testy i ukrywa zależności — lepiej wstrzykiwać zależności przez konstruktor.
4. Nazywaj rzeczy zgodnie ze wzorcem (...Builder, ...Factory, ...Strategy, ...Adapter). To ułatwia innym zrozumienie kodu bez czytania każdej linii.
5. Pamiętaj o zasadach SOLID — większość wzorców to ich praktyczne zastosowanie, zwłaszcza zasady otwarte-zamknięte i odwrócenia zależności.

Na rozmowach rekrutacyjnych pytania o wzorce zwykle sprawdzają, czy rozumiesz problem, który rozwiązują, a nie czy pamiętasz diagram UML. Jeśli przygotowujesz się do pracy z Javą w zespole, warto też dobrze poznać różnice między Gitem a GitHubem i podstawy projektowania REST API, bo to z nimi wzorce najczęściej się spotykają w codziennym kodzie.