Zrozumieć SOLID: Zasada Open/Closed

Z

Zaczynając od podstaw, SOLID to pięć podstawowych zasad pomocnych, przy tworzeniu dobrej(solidnej) architektury oprogramowania. SOLID to akronim, w którym:

  • S oznacza SRP(Single responsibility principle / Zasada jednej odpowiedzialności)
  • O oznacza OCP(Open closed principle / Zasada otwarte-zamknięte)
  • L oznacza LSP(Liskov substitution principle / Zasada podstawienia Liskov)
  • I oznacza ISP(Interface segregation principle / Zasada segregacji interfejsów)
  • D oznacza DIP(Dependency inversion principle / Zasada odwrócenia zależności)

Zasada Open/Closed

Kod powinien być otwarty na rozszerzanie ale zamknięty na modyfikacje.

Główną ideą jest, by z jednej strony kod miał swoje abstrakcje, klasy, moduły, funkcje wyższego poziomu wykonujące tylko jedną rzecz, którą robią dobrze. Chcesz, aby były one ładne, spójne i dobrze utrzymane.

Z drugiej natomiast, zmieniają się wymagania, zakres, wpadają prośby o nowe funkcjonalności i potrzeby biznesowe. Nie możesz zachować swoich cennych abstrakcji w nieskazitelnej formie przez długi czas. Nieuchronnie będziesz musiał dodać więcej funkcji lub dodać więcej logiki i interakcji. Chcesz mieć możliwość dodania dodatkowego zakresu przy zachowaniu dobrego kodu.

I właśnie tu, pojawia się ta konkretna zasada Open/Closed. Pomoże Ci ona ładnie to zrobić. Kiedy nadejdzie czas, w którym musisz zmodyfikować istniejący kod, upewnij się, że:

  • Zachowasz bieżące funkcje, klasy, moduły w aktualnym stanie lub przynajmniej zbliżonym do tego co zastałeś.
  • Rozszerzaj istniejące klasy unikając dziedziczenia tak, aby wystawiały nową funkcję pod inną nazwą.
Najtrudniejszą częścią jest z wyprzedzeniem dobrze wiedzieć, jakie później będą zmiany. Dzięki temu jesteś w stanie uczynić Twoje abstrakcje bardziej odpornymi na zmieniające się wymagania bez wielokrotnego przepisywania kodu.

W takim przypadku bardzo pomocne okazać się mogą regularne spotkania zespołu, gdzie można omawiać przyszłe funkcjonalności produktu. Bardzo ważna jest komunikacja biznes – zespół deweloperski.

Oznacza to również, że zawsze powinniśmy starać się pisać kod, który nie musi być zmieniany za każdym razem, gdy zmieniają się wymagania.

Pluginy i middleware

Zasada open/closed dotyczy również architektury pluginów i middleware’ów. W takim przypadku Twoja podstawowa encja, jest core’ową funkcjonalnością aplikacji.

W przypadku pluginów, masz moduł podstawowy i core, który można podłączyć za pomocą nowych funkcji za pośrednictwem interfejsu. Dobrym tego przykładem są przeglądarki internetowe, takie jak Chrome.

Na przykład w przypadku middleware’ów, masz cykl request-response i możesz dodać między nie pośrednią logikę biznesową. Najlepszym tego przykładem jest Redux.

Podsumowanie

Mam nadzieję, że ten artykuł zainspiruje niektórych z was do zastosowania tej zasady i skorzystania z jej cech. Kluczową sprawą jest posiadanie solidnej encji, którą można rozszerzyć w taki sposób, aby nie wypłynęło to na dotychczasową funkcjonalność. Gorąco zachęcam do zgłębiania wiedzy nt. zasad SOLID, ponieważ dzięki nim nasz kod stanie się o wiele lepszy.

O autorze

Filip Nowacki

Swoją przygodę z IT rozpoczął mając 13 lat, kiedy to stworzył swoją pierwszą stronę internetową. Obecnie pracuje jako backend & mobile developer, rozwijając kilka ogólnopolskich produktów o zasięgu blisko 15 milionów użytkowników. Prywatnie maniak optymalizacji, testów A/B, motoryzacji i architektury aplikacji.

2 komentarze

  • No właśnie… biznes, który zazwyczaj nie wie co będzie robił jutro. A Ty wymagasz od nich by powiedzieli Ci o dalszej perspektywie projektu? Litości… 😀

    • Haha, no wiesz, jak mi się biznes nie podobał to po prostu zmieniłem firmę. Praca programisty ma być przyjema 😉

Your sidebar area is currently empty. Hurry up and add some widgets.