[Ta księgarnia jest jeszcze "under development", dlatego nie linkuję. Zostało mi jeszcze kilka funkcji i zamawiam szablon.]

To, że PHP jest przede wszystkim strukturalne – widać. $f = fopen('plik') while (!feof ($f)) ... $line = fgets ($f) grrr… Czy by nie było lepsze coś w tę deseń?: $f = new FileStream ('plik') while (!$f->eof()) ... $line = $f->getLine()

Obiektowy nie upadnie, jeśli jest napisany obiektowo, a nie korzystając z mechanizmów programowania obiektowego ;) Bo obiektowo się projektuje. Chodzi właśnie o to, aby dokładnie zaplanować, co będzie potrzebne i w jaki sposób osiągnąć późniejszą łatwość konserwacji. Wzorce projektowe odgrywają tutaj bardzo ważną rolę. Pozwolę sobie zamieścić krótki cytat z książki „Wzorce projektowe. Analiza kodu sposobem na ich poznanie”, A.Holub:

Jestem zdecydowanym zwolennikiem reguł rządzących światem systemów obiektowych, ponieważ za każdym razem, gdy którąś z tych reguł łamałem, musiałem pisać cały swój kod od początku.

A Geo upadło, pisałem je lat 3 temu strukturalnie. Przeróbki były naprawdę znaczne.

Captcha – hmmm, nie widzę, żeby w ogóle była :D A odpaliłem mojego bloga w innej przeglądarce. A może Captcha dezaktywuje się po napisaniu pierwszego zaakceptowanego komentarza? Popatrzę w ustawieniach ;)

Dzięki za komentarz.

Obiektowość ma sens, jeśli są ku temu przesłanki – jeśli jest sensowne dziedziczenie i możliwości łatwej wymiany/żonglowania klasami (dobrym przykładem są operacje na obrazkach, które można zamknąć w 1 funkcji publicznej, a w prywatach dodatkowe wymagane obliczenia/operacje – jest 1 interfejs i za każdym razem wiesz jak z niego skorzystać – operacje dotyczące obrazka mogą być zapisane w bazie i w dowolnym momencie odtworzone/powtórzone). Sensowne (IMO) jest również grupowanie funkcji w klasy, jeśli dotyczą podobnych struktur danych (np. operacje na wybranym typie pliku, bądź „specyficznym stringu”) – dodawanie klasy dla 1 funkcji („simpleurl” modyfikującej string do znaków wyświetlanych w URLu) – tylko dlatego, że „wszystko ma być obiektem” jest bez sensu.

PHP był i jest językiem przede wszystkim strukturalnym. Obiektowość jest już sensownie rozwinięta, nie zmienia to faktu, że większość funkcji głównych była/jest/będzie strukturalna. Dlatego nie ma sensu całkowite wyparcie się programowania strukturalnego. Jednocześnie warto (ale tylko tam, gdzie to ma sen) używać obiektowości.

Czytanie kodu obiektowego wcale nie jest prostsze niż kodu strukturalnego (i odwrotnie). Podobnie z modyfikacją i zastępowaniem (duże serwisy) – natomiast z dopisywaniem jest już różnica – łatwiej w serwisach obiektowych.

Jeszcze co do „upadku” (geo) – jeśli było napisane niechlujnie, zmieniały się zamysły (inne zupełnie kierunki rozwoju i duuuże przebudowy) to nawet obiektowo napisany serwis stanie się z czasem trudny do modyfikacji/rozwoju (a jak jeszcze do tego dojdzie zmiana developera :D )

Co do „Javowskiego” stylu – styl ten mi odpowiada. Wg mnie jest lepszy od tego, co mamy w PHP. Co prawda w Javie pisałem tylko jeden projekt (mała gra) na zaliczenie przedmiotu, jednak trochę się z tym nakodziłem i jakieś doświadczenie w tym mam.

Nawiasem mówiąc Java ma bardzo duży wkład we wzorce projektowe, czy architekturę frameworków. Bez Javy dużo tego co mamy po prostu by nie było.

Ale mozna zaobserwowac w wielu projektach i kodach napisanych w php podejscie javowe, ktore mi osobiscie nie zbyt przypada do gustu (tak jak sama java), gdzie wszystko jest pakowane w obiekty, gdzie aby zrobic malutka rzecz trzeba utworzyc 40 instancji roznych klas i wzajemnie nimi zaglowac :P

Co do przedostatniego akapitu o upadku projektu, moge powtorzyc po raz kolejny, ze nie stalo sie to z powdu strukturalnego projektowania, bo oczywiscie projekt byl OOP. Nie co zmienily sie moje zamilowania i odejscie od webdeveloperki oraz narzut zbyt wielu obowiazkow i nowych roznorakich projektow.