OOP hell - kiedy abstrakcja przeradza się w frustrację

Wiele osób podąża tropem obiektówki na ślepo wychodząc założenia że im więcej warstw abstrakcji - tym lepiej bo przecież łatwiej będzie modyfikować, rozwijać i przenosić kod między aplikacjami (kolejna brednia, pisanie modularne zapewnia mobilność kodu a nie jego obiektowość ale to nie będzie tematem tego wywodu), zastanawiam się zatem co powiecie na taką implementację helloworld.

<?php
$helloworld = wordFactory::createWord('helloworld');
echo $helloworld;
?>

Gdzie wordFactory oczywiście wykorzystuje klasy "h", "e", "l", "o", "w", "r" i "d" które są pochodnymi klasy "letter" i produkowane są poprzez letterFactory::createLetter. Daje nam to genialną, wysoko abstrakcyjną strukturę. Dzięki takiemu poziomowi abstrakcji będzie łatwo na przykład zmienić wszystkie samogłoski z kodowania UTF8 na UTF16. Tylko czy zaciąganie całej tej architektury jest nam naprawdę potrzebne? Czy może jednak wystarczy zwykłe

<?php
echo 'helloworld'; 
?>

ponieważ ten kod raczej nie zostanie zmieniony, i nie ma sensu komplikować oraz spowalniać go dodatkowymi wywołaniami gdyż nie wynika z tego żadna korzyść. Dochodzimy tym sposobem do wniosku pierwszego:

Dodatkowa warstwa abstrakcji sama w sobie nie jest zaletą, korzyście z niej wynikające są

Ale dlaczego w ogóle odczuwamy potrzebę wykorzystania tej dodatkowej warstwy ?

Każdy który miał styczność z Zend "Frameworkiem" natychmiast zauważy że takie podejście powoduje iż podstawowa konstrukcja zf staje się... bezcelowa. Po co używać request->getPost, nie mówiąc o antipatternie (tak, w php jest to idealny przykład antipatterna) registry który nie robi nic więcej niż globalna tablica, no ale robi to oop-way! Już widzę armie ludzi wychodzących z "ale dzięki dodaniu teraz tej warstwy abstrakcji później będzie mi łatwiej robić zmiany w systemie!" na co mam tylko jedną odpowiedź - pomyśl. Pomyśl, czy zamierzasz dodatkowo komplikować aplikację ponieważ może kiedyś będziesz musiał zmienić podstawowe założenia systemu które powinny zostać przewidziane podczas projektowania aplikacji. Poważnie, czy zamierzasz kiedykolwiek zmienić sposób w jaki przekazujesz dane wewnątrz aplikacji pomiędzy klasami - podstawową architekturę twojego systemu ? Pominę już fakt że parsowanie danych przychodzących i przekazywanie ich dalej odbywa się w jednym miejscu (front controllerze jeśli mowa o typowej aplikacji MVC) i czy strukturalnie czy obiektowo, zmiany będą wprowadzane tylko w tym miejscu. Dochodzimy tym sposobem do kolejnego wniosku:

Nieumiejętność w projektowaniu aplikacji prowadzi do złych założeń czego namacalnym efektem jest oop hell

Oczywiście teraz mam kolejną porcję wściekłego tłumu na głowie ponieważ uważam że dodatkowa obiektowość komplikuje kod a przecież wprowadzenie obiektowości wręcz upraszcza zrozumienie go ponieważ klasy i relacje między nimi układają kod w logiczne klocki. Jest to prawda, dobrze przemyślane klasy układają kod w logiczną całość, ale równocześnie go komplikując ponieważ nie wystarczy po prostu zmienić 4 oczywiste linijki w kodzie, trzeba prześledzić klasa za klasą gdzie co się wykonuje aby na samym końcu dokonać zmiany. Spełzłem trochę z tematu ale chodzi mi o pokazanie wam że nie należy ślepo przestrzegać OOP (czy jakiejkolwiek metodyki) tylko przepuścić każde rozwiązanie przez filtr logiki, ponieważ ma ono zarówno wady i zalety i nie ma uniwersalnego dla każdej potrzeby.

Podsumowanie

Projektanci zapatrzeni w inne języki zapominają że to co dobre w javie, niekoniecznie musi być dobre w php z racji na podstawową różnicę - php było jest i będzie językiem hybrydowym, i zamiast wypierać z niego struktural i kopytami wpychać na siłę obiektowość - korzystajmy z możliwości jakie daje nam hybrydowość php i uproszczajmy kod zamiast go komplikować popadając w OOP hell.