W tak prostych zastosowaniach PHP + MySQL oczywiście to sensu nie ma - wystarczy tablica asocjacyjna lub zwrot mniejszych ilości pól na zwykłej liście. Ale jeśli masz złożone rekordy w "bazie", z referencjami, warstwy pośrednie i wrappery to na pewno łatwiej jest operować na obiektach niż na tablicach - tym bardziej, że obiekt to nie tylko same atrybuty (skalary, wektory itp.). Wyobraź sobie, że między N metodami musisz przekazać dużo danych - sądzę, że po 15 operacjach i przekazaniu wyniku 8 poziomów w głąb będziesz się mocno zastanawiał, na której pozycji w przekazanej liście jest wartość pola X a na której Y.
Stąd też obiektówka dobrze się sprawdza w architekturze MVC - pozwala utrzymać porządek w kodzie i czyni go przejrzystym przy wielu warstwach, dużej ilości operacji na danych. Przykład: pobierasz prosty rekord usera z bazy (same skalary w liczbie 40 pól - dużo? dużo bo np. nie chciało ci się robić żadnej normalizacji) i automagicznie "rozpinasz" go na obiekcie. Wtedy obiekt w atrybutach przechowuje dane usera (hash hasła, e-mail, login, ID itp.) a ponadto metody i inne własności zajmujące się obsługą operacji na nim tych jego atrybutach (pochodzące z "modelu" / szablonu): metody testów, pobór powiązanych referencjami danych np. coś w stylu $user->change_password($new_pwd) - o wiele czytelniejsze niż jakieś metody rozbite na X plików, które trzeba includować i odpalać po kolei (obiekt gromadzi to "w sobie" więc zawsze wiadomo gdzie tego szukać a i podczas pisania łatwiej sprawdzić co jest co bo jest kilka linii wyżej).
Przy zapisie podobnie - twój czy gotowy wrapper (o ile go używasz) troszczy się o to abyś nie musiał składać zapytania z N polami rekordu a tylko wydał polecenia zapisu obiektu ("wywalone" zostaną wszystkie metody a wartości z atrybutów grzecznie przeniesione w odp. pola bazy). Jak trzeba to i z walidacją czy rollbackiem :o
Chciałem tu dać jakiś przykład ale obecnie nic mi nie przychodzi do głowy. Nic takiego co byłoby proste a jednocześnie pokazywało tą przewagę ;)
Na pewno "return $obj;" jest bardziej eleganckie niż jakieś global-e czy return-y z tablicami długimi jak peron na Warszawie Centralnej...
Prawdę mówiąc programowanie obiektowe weszło do PHP stosunkowo późno i jeszcze się do końca nie ustabilizowało (?) brak chociażby standaryzacji w tym zakresie no i pewne "niedorozwinięcie" względem obiektówki jaką znamy z C, Javy itp. PHP było "do czego innego" tworzone... Wystarczy przypomnieć sobie jakie zmiany weszły między v4 a v5 (to był skok!) że o "bólu" pisania "ładnego oraz funkcjonalnego [i obiektowego!]" modułu do PHP nie wspomnę...
