Programowanie obiektowe? Dlaczego?

Kolejnym pytaniem, które zada sobie programista php, który już od dłuższego czasu z większym lub mniejszym powodzeniem pisze aplikacje strukturalnie, będzie "po co mam programować obiektowo jeśli już tyle czasu programowałem strukturalnie i jakoś sobie radzę?". Każdy człowiek powinien czerpać siły z powiedzenia "jeśli się nie rozwijasz, to się cofasz" - to jest najprostszy argument. Ale za programowaniem obiektowym stoi szereg bardziej istotnych plusów. Nie będę ich szczegółowo omawiał, ale wymienię niektóre z nich: kod programu jest łatwiejszy do czytania przez człowieka (czyli OOP to kolejny "poziom" programowania), elastyczność i łatwość rozbudowy aplikacji o nowe funkcjonalności, powtórne wykorzystanie kodu.

Zatrzymam się przy tej ostatniej zalecie, gdyż jest ona dwuznaczna. Z jednej strony powtórne wykorzystanie kodu umożliwia dziedziczenie, ale nie tylko o to chodzi. Dobrze zaprojektowana grupa klas, która jest odpowiedzialna za określone zadanie, może być z powodzeniem wykorzystana w całkowicie innym systemie bez żadnych modyfikacji. W podejściu strukturalnym ponowne wykorzystanie kodu polega na "kopiuj, wklej oraz przystosuj do nowych wymogów", prowadzi to do konieczności powtórnych testów, niejednokrotnie ten sam kod jest powielany w wielu miejscach aplikacji, co utrudnia ewentualną modyfikację tego fragmentu kodu (zmiana w jednym miejscu musi być naniesiona również w drugim, aby była zachowana synchronizacja).

Nie będę udowadniał wyższości OOP nad strukturą, gdyż nie to jest celem tego artykułu. Dla równowagi napiszę jeszcze o jednej (małej) wadzie podejścia obiektowego. Programowanie strukturalne w php jest wydajniejsze (zwłaszcza w php4), ale jednak nie na tyle aby ten aspekt przysłonił plusy OOP.