Kwiecień
07
2009

Zasada otwarcia i zamknięcia

Słowa kluczowe: , | Kategorie: Projektowanie
No Gravatar

software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification

elementy oprogramowania (klasy, moduły, funkcje itp.) powinny być otwarte na rozbudowę, ale zamknięte na zmiany

źródło: Wikipedia

Zasada brzmi niezwykle mądrze, zawiera ważne przesłanie i… jest kompletnie niezrozumiała. Generalnie chodzi o to, żeby funkcjonalność programu można było zawsze rozszerzyć, ale bez dokonywania zmian w istniejącym kodzie… teraz to już w ogóle nie wiadomo, o co chodzi. Należy zmieniać bez dokonywania zmian?

Może najlepiej wyjaśni to przykład. W programie do obróbki zdjęć wykorzystywane są różne filtry, posiadające jednolity interfejs:

public interface Filter {
    void apply(Image image);
    void undo(Image image);
}

Istnieją też dwie implementacje tego interfejsu – GaussianBlurGammaCorrection. Program posiada następującą funkcjonalność:

  • rozmycie Gaussa,
  • zmana jasności obrazu.

Jeżeli zajdzie potrzeba rozszerzenia funkcjonalności o rozmycie w ruchu, wystarczy dodać nową implementację interfejsu FilterMotionBlur. Funkcjonalność zostanie rozszerzona, a wcześniejszy kod źródłowy nie ulegnie zmianie.

Rozwiązanie opiera się między innymi o zastosowanie interfejsów – jak w przypadku hermetyzacji zmienności, jednak bardzo ważne jest też tworzenie klas o niewielkim zakresie odpowiedzialności. Gdyby za różnego typu rozmycia odpowiadała jedna klasa Blur, zaś wybór między rozmyciem Gaussa a rozmyciem w ruchu był realizowany poprzez parametr, zmiany w kodzie byłyby nieuniknione.

Napisz Komentarz

*