Czy PHP naprawdę jest badziewne? Opcje

[PHPDeveloper]

Czy faktycznie każdy rozumny człowiek powinien omijać PHP szerokim łukiem? Największe serwisy internetowe powstały w PHP (Facebook, YT). Internet jest zalany artykułami o beznadziejności PHP. Czy jest tak w rzeczywistości? Jakie są powody by tak twierdzić? Jeff Atwood stara się to wyjaśnić. SPAM

Ten post edytował erix 14.09.2009, 21:45:27

Powód edycji: [erix]: znowu ten sam link, moderka do odwołania [Ociu]: Usunąłem link.

[wookieb]

I najlepsze co może być, moim zdaniem, to budowanie modelu właśnie w oparciu o te cegiełki-obiekty.

A ja właśnie uważam zupełnie inaczej.
Obiekty służa ładnym uporządkowaniu pewnych funkcjonalności i przejrzystość w korzystaniu z pewnych elementów lecz z ich wykorzystaniem nie przesadzajmy. Nie wszystko musi być obiektem i skoro NIE MUSI nim być to lepiej użyć prostszych i mniej zasobożernych rozwiązań. Obiekt zajmuje znacznie więcej miejsca w pamięci i jeżeli jego użycie nie przyniesie większych korzyści niż zaoszczędzenie sobie jednej linijki kodu to wolę użyć tablicę.

Weźmy chociażby dekoratory w Zend_Form. Noż nie wiem kto coś takiego wymyślił, że każda pierdoła zwykły tag musi być obiektem. W dużym formularzu robi się tych obiektów multum (i multum zapchanej pamięci). A czy nie można było tego zrobić prościej? Chociażby wyświetlanie pojedynczego elementu powierzyć jednemu plikowi szablonu? Ile by się przy tym zaoszczędziło czasu programisty i zasoby serwera.

Weźmy kolejny przykład. Nienawidze nie ścierpie "Mądrego" podejścia większości zendowców. Przesadzają z wykorzystaniem kupy narzędzi, które tak naprawdę są bardzo mało (a czasem nawet wcale) potrzebne.
Przykład. Zastępując require_once metodą Zend_Loader::loadClass . No to cholere? Po co ładować taka banalną rzecz w coś co zrobi to samo tylko, że wolniej (znacznie) oraz żadnej super funkcjonalności nie przynosi. Niedługo dojdzie do tego, że echo zastąpią jakąś klasą.

Najśmieszniejsza rzecz z jaką się spotkałem w świecie zendowców to... żeby usunąć rekord należy go pobrać i dopiero usunąć??

Kolejny kwiatek (nie wiem czy da się to wyłączyć czy też nie, zresztą już mnie to nie interesuje). Po kiego do Zend_Db_Table_Row wrzucany jest mi schemat całej tabeli z szeroką gamą informacji o danej kolumnie? Jak będe potrzebował to sobie sam te informacje pobiore. Koszt jaki tym ponosze? Kolejne marnotrawienie pamięci. O ile da się to w pewien sposób wyłączyć (rozszerzając tą klasę) to i tak klasa rodzica zostaje w pamięci marnotrawiąc kolejne zasoby.

Czy takie marnotrawienie pamięci rzeczywiście jest złe? Oczywiście. Pewnego razu tworzyłem serwis, który posiada dużą ilość osób online na raz (1500), oraz mnóstwo wywołań ajaxowych. Przepisałem cały serwis na super mini mvc. Były m.in takie obiekty (baza danych, obsługa urla, session_handler, kontroler (abstract)) i co? Padło w pierwszym dniu. Trzeba było przywrócić starą wersję i trochę ją posprzątać. Gdzie było zmarnotrawienie pamięci i czasu procesora? A no sparsowanie urla, znalezienie i zainicjowanie kontrolera nie jest tak naprawdę bardzo konieczne (można przecież nawet na potrzeby jednego serwisu potworzyć pare plików .php które parsowanie urla nam oszczędzą (wiadomo nie wszędzie da się tak zrobić) a kontroler też nie jest tak do końca konieczny. Każda taka pierdoła ma ogromne znaczenie przy dużych serwisach, a i przy małych na jednym serwerze potrafi dać pewne oznaki swojej obecności. O ile w podanym przeze mnie przypadku taka pierdoła jest naprawdę mała to już wolę sobie nie wyobrazić jak wielkim wąskim gardłem jest duża ilość rozwiązań z zenda.

Dlatego tak bardzo jest ważne rozsądne korzystanie z obiektowości i nie robienie wielkiego śmietnika, który potrafi dużo ale też bardzo dużo może nas kosztować. I jeżeli, ktoś mówi "autorski FW pewnie nie umie tyle co taki (ten ten a ten i tutaj szeroka lista)" to jest to żaden argument. Ale DOBRZE, że właśnie ten autorski FW nie umie tyle, ale za to ma tyle ile potrzebuje i nie wali kupy w pamięci jeżeli nie jest to konieczne.