Jaki sens obiektowego projektowania php - PHP
Farnell, An Avnet Company   Przedstawicielstwo Handlowe Paweł Rutkowski   Fluke Europe B.V.  

Energetyka, Automatyka przemysłowa, Elektrotechnika

Dodaj firmę Ogłoszenia Poleć znajomemu Dodaj artykuł Newsletter RSS
strona główna GRUPY PHP Jaki sens obiektowego projektowania php
REKLAMA
Przejdź do grup
REKLAMA

Jaki sens obiektowego projektowania php

Awatar użytkownika
Artur Kulikowski

Witam, chciałbym poznać wasze opinie na temat obiektowego projektowania aplikacji/skryptów php. Pisząc skrypty robiące 'coś' z bazą coś wyświetlające nie bardzo widzę sens obiektowego podchodzenia do sprawy no może z wyjątkiem obiektowego odnoszenia się do wyniku zapytania do bazy.

Dobra sens może być taki jak z css w html definiuję coś i potem siędo tego odwołuję z 'mniejszych' elementów składając tą samą całość może oszczędzając trochę miejsca na kod, tylko, że jeżeli obiektu danej klasy nie używa się na stronie więcej niż 1-2 razy to oszczędności (kb) nie ma.

cytuj pomógł zgłoś nadużycie
Brak awataru
Brak użytkownika

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ę...

cytuj pomógł zgłoś nadużycie
Brak awataru
Brak użytkownika

OOP obecnie chyba już na dobre weszło w kanony programowania. Najbardziej przydaje się przy rozbudowie aplikacji bo jest porządek.

cytuj pomógł zgłoś nadużycie
odpowiedz
REKLAMA
Nasze serwisy:
elektrykapradnietyka.com
przegladelektryczny.pl
rynekelektroniki.pl
automatykairobotyka.pl
budowainfo.pl