„Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.”
— Bertrand Meyer

Czym jest zasada OCP?

Zasada OCP (Open/Closed Principle) mówi, że nasze klasy i moduły powinny być:

• otwarte na rozbudowę – możemy dodać nowe zachowanie,
• zamknięte na modyfikację – nie musimy zmieniać istniejącego kodu.

Brzmi magicznie? W praktyce chodzi o to, aby nie grzebać w działającym kodzie, tylko go rozszerzać. Dzięki temu:

• nie psujemy tego, co już działa,
• kod jest bardziej odporny na zmiany,
• nowe funkcjonalności łatwiej dodać niż napisać od nowa.

Przykład łamania OCP – instrukcja z if / switch

Wyobraź sobie klasę RaportGenerator, która generuje różne typy raportów: PDF, Excel, CSV.

public class RaportGenerator {
    public void generujRaport(String typ) {
        if (typ.equals("PDF")) {
            // generuj PDF
        } else if (typ.equals("EXCEL")) {
            // generuj Excel
        } else if (typ.equals("CSV")) {
            // generuj CSV
        }
    }
}

Problem? Każde dodanie nowego typu raportu wymusza modyfikację tej klasy. To łamie zasadę OCP. Kod działa, ale z każdym rozszerzeniem robi się coraz trudniejszy w utrzymaniu.

Lepsze podejście – polimorfizm

Zamiast modyfikować istniejącą klasę, pozwólmy ją rozszerzać przez interfejs:

public interface GeneratorRaportu {
    void generuj();
}

public class GeneratorPDF implements GeneratorRaportu {
    public void generuj() {
        // generuj PDF
    }
}

public class GeneratorExcel implements GeneratorRaportu {
    public void generuj() {
        // generuj Excel
    }
}

A następnie:

public class RaportGenerator {
    private GeneratorRaportu generator;

    public RaportGenerator(GeneratorRaportu generator) {
        this.generator = generator;
    }

    public void generujRaport() {
        generator.generuj();
    }
}

Teraz, aby dodać np. generowanie raportu do JSON, tworzysz nową klasę GeneratorJSON, a nie dotykasz starego kodu.

Korzyści z OCP

• Bezpieczne zmiany – nie ruszasz sprawdzonego kodu, tylko dodajesz nowy.
• Czysta architektura – każdy nowy przypadek to osobna klasa.
• Łatwiejsze testowanie – testujesz konkretne klasy, nie całe if-else.
• Przygotowanie pod wzorce projektowe – jak Strategy, Factory, Decorator.

Podsumowanie

OCP to zasada, która pozwala rozwijać projekt bez ryzyka rozwalenia tego, co już działa.
Jeśli widzisz w swoim kodzie rosnące if-else lub switch, pomyśl: „czy nie da się tego rozdzielić na klasy?”

Twoje klasy powinny być jak zestaw LEGO: coś można dobudować, nie niszcząc istniejącej konstrukcji.