|
In ceea ce priveste paradigma de programare propusa de phprel, trebuie stiut ca nu am ales clasica paradigma OOP. Pentru a maximiza eficienta in dezvoltare, paradigma propusa de phprel este o combinatie intre programarea structurata si programarea reflectiva.
Mai intai, sa vedem ce inseamna OOP. Programarea orientata-obiect presupune incapsularea datelor si a metodelor de manipulare a acestora in obiecte cu roluri specifice, iar aplicatia este rezultatul interactiunii dintre obiecte. Obiectele similare vor fi definite ca instante ale aceleiasi clase, iar o clasa poate extinde functionalitatea altei clase (sau a mai multor clase, in functie de limbajul folosit).
Aceasta paradigma este eficienta atunci cand sursele scrise sunt foarte mari (depasing zeci de mii de linii), iar aplicatia presupune lucrul cu multiple entitati similare, care trebuie sa ramana indepedente dar sa interactioneze cu multiple alte entitati.
Un exemplu evident ar fi folosirea OOP in dezvoltarea aplicatiilor de tip GUI, folosind medii de programare vizuale. O aplicatie de management al resurselor unei firme, de exemplu, va folosi sute de ecrane care au aceleasi proprietati (pot fi mutate, minimizate, etc.), sute de formulare care au campuri cu proprietati similare (utilizatorul poate introduce sau sterge date, copia sau lipi informatie, etc.), sute de listari ale informatiilor din tabelele bazei de date cu proprietati similare, etc.
In aceasta situatie, definim clase de obiecte (precum form, control, si de aici derivam textbox, gridview, etc.) si fiecare element al aplicatiei devine o instanta a clasei potrivite.
In mediul web insa, folosirea OOP in ultima vreme tinde sa devina o simpla moda. Intalnim deseori situatii in care asa zisele clase controller sunt folosite pentru a instantia un singur obiect, controllerul propriu-zis folosit pentru a raspunde la evenimentul curent, sau pentru a afisa pagina curenta.
De cele mai multe ori, in dezvoltarea web, pur si simplu nu exista mai multe "obiecte" similare, care sa necesite instantiere dintr-o aceeasi clasa. De exemplu, afisam o singura pagina la un moment dat, totusi creem o clasa care mosteneste o clasa abstracta "page" si instantiem un singur obiect "pagina_curenta" pe care il folosim pentru a afisa pagina.
OOP a fost conceput pentru a crea sute, daca nu chiar mii de obiecte din aceeasi clasa, intre care nivelul de interactiune este foarte ridicat, iar integritatea datelor trebuie asigurata (prin incapsulare) automat, altfel s-ar pierde sirul tuturor instantelor si ar putea aparea usor erori. In web insa, cel putin pana la nivelul aplicatiilor foarte mari, care ar reprezenta maxim 5% din piata, nu exista multiple obiecte apartinand unei aceleiasi clase care sa fie instantiate in acelasi timp. Si mai mult, clasele sunt simple, continand cateva metode, iar procedeul de mostenire nu este practic folosit.
Controller-ul mosteneste o clasa abstracta controller, modelul o clasa abstracta model. Mai departe de atat (un nivel), nu exista si nu se foloseste mostenire. Ca o comparatie, in proiectarea aplicatiilor de tip GUI, o clasa poate fi rezultatul a zeci de mosteniri, uneori multiple.
Exista de asemenea aplicatii pe web care pretind a fi orientate-obiect, dar singura aparitie a unui concept OOP este la inceputul fiecarui fisier prin folosirea construct-ului "class". Uneori, clasele sunt folosite ca simple alternative la namespace-uri, fara a instantia macar un singur obiect. Se defineste o clasa "pagina" si se apeleaza o metoda "pagina::metoda" undeva in cadrul scriptului. Acesta este un fals exemplu de OOP, care e poate util doar ca artificiu.
Cu phprel, veti castiga timp si prin insasi faptul ca nu veti scrie la inceputul fiecarei pagini class (denumire) extends Page { ... } sau la inceputul fiecarei descrieri de tabel class (denumire) extends Model { ... }. Veti mai castiga timp prin insasi faptul ca nu trebuie sa instantiati un singur obiect al unei clase care nu a mostenit decat o clasa abstracta, lipsita de functionalitati, de exemplu: $pagina = new (denumire); $pagina->afisare().
Cu phprel, pur si simplu programati, in cel mai natural stil. Descrierile de tabel se comporta singure ca si cum ar fi obiecte dintr-o clasa, dar nu e necesar sa apara codul propriu-zis de definire a clasei. Ca o paranteza, in ceea ce priveste aplicatiile web medii spre mari, medii si mici, se pare ca singurul moment in care ar fi util OOP-ul este la crearea modelelor pentru fiecare tabel din baza de date. Intr-adevar, aici se instantiaza mai multe obiecte, cu toate ca se definesc N clase corespunzatoare celor N tabele, si tot N obiecte, fiecare din cate o clasa (din nou, ineficient).
Impartirea codului in phprel este naturala: fiecarei pagini ii corespunde un php, fiecarei element de pagina un alt php (cu scope local, pentru a nu suprapune variabile), fiecarui tabel ii corespunde o descriere, etc. Si avand in vedere proportia foarte mare de cod php care va lipsi pur si simplu, deoarece functionalitatile respective vor fi asigurate automat de asistentul phprel, lizibilitatea codului si posibilitatea reutilizarii sale sunt maxime.
Am vorbit la inceput despre o asemanare cu programarea reflectiva. Va invitam sa explorati exemplele referitoare la functii de control al datelor, pentru a intelege mai bine in ce mod am folosit reflection-oriented programming pentru a simplifica sarcinile dumneavoastra si a maximiza eficienta framework-ului. Suficient sa spunem ca prin simpla scriere a unei functii cu o denumire ce poate fi recunoscuta de nucleul phprel, acea functie va fi integrata automat in firul de executie al scriptului, fara alte linii de cod.
|
