Kwalifikacja: INF.04 - Projektowanie, programowanie i testowanie aplikacji

Często spotykam się z przekonaniem, że budowanie programów opartych na modułach z funkcjami i zmiennymi globalnymi jest wystarczające, zwłaszcza w mniejszych projektach. Jednak takie podejście prowadzi do dużej trudności w utrzymaniu i rozwoju aplikacji, szczególnie gdy program zaczyna rosnąć. Globalne zmienne powodują tzw. efekt uboczny – nie wiadomo gdzie i kiedy ich stan się zmienia, co niesamowicie utrudnia debugowanie i wprowadzanie nowych funkcjonalności. Pętle dyspozytora i reakcja na zdarzenia to raczej domena programowania proceduralnego lub prostych systemów sterowania, ale nie oddają istoty programowania obiektowego – tu nie chodzi o centralne zarządzanie funkcjami, tylko o to, żeby obiekty same wiedziały, jak mają na siebie reagować. Zdarza mi się widzieć takie podejście w starszych aplikacjach, gdzie cała logika mieści się w jednym dużym pliku z wielką pętlą i masą instrukcji warunkowych – naprawdę trudno takie rozwiązania rozwijać bez wpadania w spaghetti code. Co do definicji warunków końcowych jako sposobu zarządzania programem, to jest to raczej element algorytmiki, a nie struktury aplikacji obiektowej. Moim zdaniem takie myślenie wynika z braku zrozumienia, jak ważna jest modularność i enkapsulacja w programowaniu obiektowym. Branżowe standardy (np. SOLID, DRY) podkreślają, że kod dobrze podzielony na obiekty i odpowiedzialności minimalizuje błędy i pozwala łatwo rozbudowywać aplikacje. Wspólna praca wielu instancji klas, każdej z jasno zdefiniowaną rolą, pozwala na tworzenie dużo bardziej elastycznych i odpornych na zmiany systemów. Jeśli ktoś nadal opiera projekt na globalnych zmiennych czy centralnej pętli, to prędzej czy później napotka na ścianę komplikacji, której można łatwo uniknąć, stosując paradygmat obiektowy.