Interne de inginerie a unui cadru RAD... ca dezvoltator PHP cu Nooku

Fiecare are propriul set de instrumente. În calitate de dezvoltator PHP, unul dintre preferatele mele este un cadru de dezvoltare rapidă a aplicațiilor numit „Nooku”. În cuvintele grupului de dezvoltare: „Nooku este mai mult un set de instrumente de dezvoltare web decât un cadru”.

În cazul în care nu sunteți familiarizat cu el, aruncați o privire. Este un proiect open source care folosește în mod intens modelele de design acceptate în industrie pentru a produce aplicații foarte componentizate, care sunt ușor extensibile și reutilizabile (create inițial de unul dintre dezvoltatorii principali Joomla!). Din cutie, Nooku vă oferă o mulțime de instrumente de dezvoltare rapidă a aplicațiilor pentru a ajuta proiectele să demareze mai repede. Un eșantion mic, dar puternic:

• O implementare implicită a MVC în care tot ce trebuie să faceți este să scrieți aspectul (acesta este ceea ce m-a atras)
• Disponibilitate HMVC imediat
• Suport pentru diferite formate de ieșire, cum ar fi JSON și XML pentru toate datele dvs. (adică, expuneți API-ul în câteva minute)
• Implementări administrative și front-end implicite

În centrul Nooku se află principiul de design „Compoziție peste moștenire” (de fapt, este primul concept de pe pagina introductivă Nooku. Într-o singură linie: ar trebui să urmăriți să compuneți (sau să adăugați) funcționalitatea mai multor obiecte pentru a crea unele un fel de obiect compus, mai degrabă decât să se bazeze pe subclasare.

Acest principiu vă permite să scrieți mai puțin cod și adesea duce la niște soluții destul de elegante. Deci cum anume este promovat? Ei bine, la nivel de cod, cele mai bune exemple vin prin utilizarea Mixins și a identificatorilor de resurse/servicii. Hai să aruncăm o privire.

Mixinul

Înainte de PHP 5.4, limbajul nu avea conceptul de Trăsături . Acestea sunt structuri asemănătoare clasei care, atunci când sunt „utilizate” de către un obiect, oferă un anumit tip de funcționalitate (similar cu Moștenirea Multiplă). Nooku a rezolvat această problemă de ani de zile (de la PHP 5.2) cu Mixin .

Mixin nu numai că vă permite să compuneți obiecte împreună, dar adaugă și metodele fiecărui obiect mixt la interfața obiectului compus. Obiectul care folosește mixin-ul pare să „moștenească” metodele amestecate în obiect.

 /** * Mixin an object * * When using mixin(), the calling object inherits the methods of the mixed * in objects, in a LIFO order. * * @param KMixinInterface $object An object that implements KMinxInterface * @return KObject */ public function mixin(KMixinInterface $object) { $methods = $object->getMixableMethods($this); foreach($methods as $method) { $this->_mixed_methods[$method] = $object; } // Set the mixer $object->setMixer($this); return $this; }

Aproape toate obiectele din Nooku au această abilitate deoarece extind clasa de bază KObject care a definit metoda mixin .

Clasele majore din arhitectura controlerului Nooku provin, de asemenea, din KObject. Controlerul abstract este clasa KControllerAbstract și prin inspecție puteți vedea că profită imediat de capacitatea de Mixare. Ori de câte ori este construită o instanță a acestei clase, funcționalitatea KMixinCommand și KMixinBehavior este adăugată imediat la interfața sa. În consecință, fiecare controler din Nooku este compus cu funcționalitatea de management al lanțului de comandă și al comportamentului prin obiectele respective.

Revenind la controlerul Nooku: clasa KMixinBehavior deține toate piesele pentru a oferi KControllerAbstract capacitatea de a încărca anumite comportamente în timpul execuției. Strategiile comportamentale sunt clase care descriu un proces sau o logică care poate fi separată și utilizată de alte clase (de exemplu, editabilă, ordonabilă). KMixinBehavior este destul de simplu și are doar patru metode: getBehavior, hasBehavior, addBehavior și getBehaviors. Și asta este tot ce avem nevoie pentru a oferi unui obiect capacitatea de a manipula și de a încapsula diferite strategii comportamentale.

În mod similar, KMixinCommand are doar trei metode: getCommandContext, getCommandChain, setCommandChain. Dacă nu ați ghicit, aceste trei metode oferă lui KControllerAbstract capacitatea de a implementa un lanț de comandă, dar îi permit să facă acest lucru în timpul execuției.

Vă puteți gândi la această amestecare ca la o simplă adunare aritmetică:

Ne oferă o interfață care arată astfel:

Prin definiție, clasele abstracte sunt menite să fie extinse și astfel, prin magia moștenirii, toate obiectele care sunt copii sau instanțe ale KControllerAbstract câștigă, de asemenea, capacitatea de a adăuga comportamente și un lanț de comandă în timpul execuției.

Suna bine. Dar ce înseamnă asta de fapt? Pe scurt, Nooku oferă funcționalitate componentizată; adică, Nooku vă permite să vă modularizați funcționalitatea și să compuneți funcționalități între module în timpul execuției.

Aceste două exemple servesc la demonstrarea compoziției. Ele servesc, de asemenea, pentru a demonstra suportul cadrului Nooku RAD pentru o compoziție ulterioară în centrul său. Acesta este un avantaj important. Metodele adăugate la KControllerAbstract de mai sus acceptă „Modelul de proiectare a strategiei”, oferind dezvoltatorilor instrumentele pentru a încapsula ceea ce variază înainte de a fi scrisă o linie de cod. Faptul că metoda mixin() face parte din fiecare extensie a KObject înseamnă că puteți defini și adăuga cu ușurință alte interfețe de management comportamental la majoritatea obiectelor în timpul execuției.

Identificatori și localizatori de servicii și resurse: Decuplați numele clasei mele de obiectul meu

Identificatorii și localizatorii de servicii și resurse din Nooku oferă, de asemenea, un suport puternic pentru separarea preocupărilor.

Din nou, să ne uităm din nou la KObject, dar și la KService. Putem trata majoritatea lucrurilor din Nooku ca pe un serviciu sau o resursă și, ca atare, le putem instanția și interoga exact în același mod.

Când mergeți la un magazin alimentar și cumpărați un produs, gândiți-vă la magazin ca la Serviciu, adică la o colecție de articole pe care le puteți răsfoi ; și produsul ca Resursă, adică o singură logică de articol/soluție care poate fi:

• privit în mod specific ( Citiți ) (de exemplu, uitându-vă la o cutie de supă de roșii)
• mutat prin magazin ( editat ) (de exemplu, mutați supa pe culoarul cu produse)
• adăugate sau eliminate din inventarul magazinului ( A dd and Elete ) (de exemplu, adăugați un nou tip de supă și scăpați de roșie)

Luând acest exemplu și mai departe, imaginați-vă că magazinul alimentar are un departament de franciză și doriți să fiți în afaceri. În această situație, Serviciul este departamentul de franciză, iar resursa este magazinul alimentar pe care îl cumpărați. Este foarte mult o clasificare contextuală. În ansamblu, acesta este cunoscut sub denumirea de modelul de acțiune BREAD (veți vedea fiecare dintre acestea reprezentat între KControllerService și KControllerResource precedat cu „_action”, adică _actionRead()).

Un model poate fi un serviciu, un obiect tabel poate fi gândit ca un serviciu, o anumită triadă MVC este instanțiată ca o resursă sau serviciu, în timp ce o înregistrare specifică rezultată din interogarea serviciului poate fi gândită ca o resursă.

Fiecare obiect din Nooku este o compoziție de obiecte, deoarece fiecare dintre ele conține o referință la serviciile instanțiate ale întregii aplicații într-un „container de servicii” și o metodă de acces la serviciile numită getService(). Tot ceea ce este cerut de metoda KObject::getService() este să transmitem un identificator de resursă valid și acesta va returna un serviciu instanțiat gata de utilizare.

În dezvoltarea rapidă a aplicațiilor PHP, identificatorii de resurse ne oferă o modalitate puternică de a decupla instanțiarea unui obiect de numele clasei sale și, astfel, de a furniza aliasuri pentru acea identificare. Acest lucru are implicații importante asupra mentenanței unei aplicații. Prin alias, un dezvoltator poate schimba clasa folosită de fiecare obiect care este instanțiat cu un identificator dat, adăugând o linie de cod cu KService::addAlias().

Un exemplu de identificator de resursă cu care suntem familiarizați este URI-ul sau Uniform Resource Identifier:

Acestea sunt toate informațiile necesare pentru ca KService să localizeze și să încarce clasa corespunzătoare. Aceste piese se potrivesc cu convențiile de plasare și denumire a clasei Nooku, care oferă predictibilitate a plasării și instanțierii. Exemplul de identificare de mai sus (com://site/user.database.table.user) încearcă să încarce fișierul /components/com_user/databases/tables/user.php, care are un nume de clasă ComUserDatabaseTableUser. De altfel, dacă fișierul nu există, cadrul vă va oferi un obiect tabel implicit și îl va construi pe baza convențiilor de denumire a bazei de date și a schemei de id-uri (acest lucru m-a mai atras). După cum am menționat anterior, KService vă permite, de asemenea, să setați alias-uri pentru identificatorii dvs. Utilizarea KService::setAlias('maindbaseadapter','com://admin/default.database.adapter.mysqli') ; ne permite să încărcăm un obiect db cu KService::getService('maindbaseadapter') .

Acest lucru ne oferă decuplarea despre care am vorbit și oferă un avantaj marcat în întreținerea și extinderea aplicațiilor noastre. Suntem liberi să creăm alte aplicații decât „site” și „admin”, dacă este necesar și prin identificatorii descriși aici putem folosi cu ușurință serviciile situate în alte aplicații pentru a ajuta soluțiile noastre să îndeplinească cerințele acestora. Din nou, acesta este un alt exemplu al modului în care Nooku oferă dezvoltatorilor și echipelor PHP și RAD suport pentru compoziția nu numai a obiectelor de o singură clasă, ci și a serviciilor și aplicațiilor întregi... gratuit.

Rezumând

Cu compoziția peste moștenire în inima sa; compozițiile și structurile inteligente, preexistente, care există pentru a susține amalgame ulterioare; și arhitectura gratuită orientată spre servicii cu identificatorii descriși aici, Nooku oferă un cadru RAD puternic, cu un avans semnificativ față de oricare dintre instrumentele sale de dezvoltare PHP egale.