Mroczne strony Open-Closed Principle

detektywi.it 9 miesięcy temu

Prostota jest celem, a nie punktem wyjścia do osiągnięcia celu.

Sean Parent, Menlo Innovations

Zasada otwarte-zamknięte (Open-Closed Principle), opisana w SOLID, zapewnia elastyczność projektu, jednak czy zawsze prowadzi to do optymalnego, gotowego na przyszłe zmiany kodu? Brzmi ona obiecująco – otwarte na rozszerzenie, zamknięte na modyfikację. Przyjrzyjmy się jej bliżej.

Overengineering w świetle Open-Closed

Zasada otwarte-zamknięte zdaje się być rozsądnym podejściem. Projektując nasz kod tak, by łatwo było dodawać nowe funkcje bez modyfikowania istniejącego kodu, stajemy się gotowi na niespodziewane zmiany i rozwinięcia projektu. Jednakże, czy zawsze jest to konieczne? Właśnie w tym momencie pojawia się problem – overengineering.

Overengineering to sytuacja, w której nasz kod jest bardziej skomplikowany niż to konieczne w celu przygotowania na zmiany i scenariusze, które mogą nigdy nie zaistnieć. Jest to jak budowanie mostu na pustyni, w nadziei, iż może kiedyś się przydać jako korytarz handlowy.

Wychodzenie naprzeciw potencjalnym, ale niewiadomym, zmianom może prowadzić do nadmiernego abstrahowania kodu. Dodatkowe warstwy, interfejsy i struktury, które mają zapewnić nam elastyczność, ale jednocześnie wprowadzają zbędną złożoność. Dodatkowa złożoność jest wprowadzana aby w przyszłości nie musieć dotykać poszczególnych fragmentów kodu. To właśnie strach przed przyszłą zmianą napędza overengineering. Strach którego źródłem jest kiepskiej jakości kod.

Właściwa inżynieria

Zamiast skupiać się na tworzeniu kodu, który jest gotowy na każdą ewentualność, warto skoncentrować się na adekwatnej inżynierii. Zamiast unikać zmian, skupmy się na tworzeniu kodu, który jest łatwy do zmiany. Wysoka jakość kodu, clean code, automatyczne testowanie, modularyzacja, wysoka spójność itd. – to są fundamenty, które sprawiają, iż nasz kod staje się elastyczny bez zbędnych abstrakcji.

Inżynieria powinna być zorientowana na tworzenie rozwiązań, które są proste i efektywne. Dla przykładu gdy masz jeden algorytm naliczania zniżki, nie musisz od razu implementować strategii (strategy pattern) z myślą “a może kiedyś będziemy mieli drugi algorytm i będzie łatwo go podmienić”. To jest overengineering całkowicie zgodny z zasadą otwarte-zamknięte. jeżeli kod jest dobrej jakości wprowadzenie abstrakcji wtedy gdy będzie potrzebna nie powinno stanowić problemu.