Share
Pentru cei care au o experiență vastă în ingineria software, modelele de design ar trebui să fie teritoriu familiar; cu toate acestea, există un întreg grup de dezvoltatori - în special în comunitatea de dezvoltare web - care nu sunt neapărat familiarizați cu modelele de design (chiar dacă le-au folosit probabil!).
În această serie, vom examina modelele de design, în special în contextul WordPress, cum sunt utile și câteva exemple practice pe care le putem folosi în temele și pluginurile noastre.
Scopul final al seriei este de a oferi o definiție solidă a tipurilor de design, de ce sunt utile, de modul în care sunt folosite în corelația cu WordPress și apoi de a revedea două exemple populare pe care le putem folosi cu ușurință în munca noastră.
Înainte de a ajunge la o privire la câteva exemple practice, să definim modele de design și să examinăm un exemplu de modul în care sunt utilizate în WordPress core.
Pentru aceia dintre voi care nu au auzit niciodată sau care nu au folosit niciodată modele de design, este important să înțelegeți ce sunt înainte de a începe să le folosiți în munca noastră.
Wikipedia oferă următoarea definiție:
Un model de design în arhitectură și informatică este un mod oficial de documentare a unei soluții la o problemă de proiectare într-un anumit domeniu de expertiză. O colecție organizată de modele de design care se raportează la un anumit câmp se numește un limbaj de model.
Poate că o definiție mai simplificată ar fi:
Un model este un design care poate fi aplicat unei probleme într-o anumită situație.
Dacă asta e încă nu e clar, gândește-te în felul acesta:
Implementarea generală și arhitectura vor arăta exact la fel; totuși, specificul implementării va varia, în mod firesc, de la proiect la proiect, însă aceasta este pur și simplu natura fiarei.
În secțiunile viitoare și în articolele viitoare, vom examina acest lucru într-un mod mai detaliat.
Dacă ați făcut orice tip de dezvoltare WordPress care implică sistemul de cârlig - adică ați scris intregi pluginuri, teme sau chiar o funcție simplă și ați profitat de ADD_ACTION sau add_filter funcții - atunci ați folosit modele de design.
WordPress utilizează ceea ce se numește un model de design bazat pe evenimente. Există mai multe variante ale modelelor de design bazate pe evenimente, dintre care vom examina momentan, dar elementele tipice ale tiparelor sunt la fel:
În general vorbind, editorul difuzează un mesaj ceva sa întâmplat la toate obiectele care sunt abonate la editorul respectiv.
O altă modalitate de a privi acest lucru este că, în software, ori de câte ori se întâmplă ceva, spunem că se ridică un eveniment. Poate cel mai obișnuit loc pe care îl vedem în dezvoltarea web este în JavaScript cu lucruri cum ar fi mouse-ul pe care se face clic, o tastă de pe tastatură fiind apăsată sau ceva similar.
Apoi, scriem funcții care gestionează aceste funcții și aceste funcții sunt denumite în mod corespunzător ca manipulatoare de evenimente deoarece sunt responsabile pentru manipularea cazului atunci când se întâmplă un eveniment.
Nu e complicat, nu? Sincer, uneori cred că terminologia poate fi mai confuză decât implementarea reală.
Deci, oricum, în contextul WordPress - sau al oricărei aplicații web, în acest caz - evenimentele nu se limitează la apăsările de taste sau clicurile de mouse. În schimb, se poate întâmpla în diferite părți ale ciclului de încărcare a paginii, când datele sunt scrise în baza de date, atunci când datele sunt citite în baza de date și așa mai departe.
În cele din urmă, puteți implementa modelul, oricum doriți, astfel încât să puteți oferi cârlige în care dezvoltatorii pot înregistra funcții de foc în momentul în care apare evenimentul.
Acest lucru ne aduce cercul complet înapoi în arhitectura WordPress: Cârligele sunt plasate în întregul cod astfel încât să putem înregistra o funcție de foc ori de câte ori ceva se întâmplă (adică, de fiecare dată când se întâmplă un eveniment).
Există o serie de modele de design bazate pe evenimente, dintre care unul este cunoscut sub numele de Modelul de Observer. Acest tipar special este, de asemenea, cunoscut sub numele de Editor-Subscriber Pattern sau, mai concis, Pub-Sub.
În cea mai simplă implementare a acestui model, există un singur editor care este responsabil pentru difuzarea mesajelor către unul sau mai mulți abonați. Abonații sunt responsabili pentru înscrierea la editor și apoi editorul este responsabil pentru trimiterea unui mesaj sau luarea de măsuri pentru toți abonații.
O diagramă la nivel înalt ar arăta astfel:
Din perspectiva codului, editorul are nevoie de trei lucruri:
În mod similar, Abonatul trebuie să poată face două lucruri:
Există o serie de moduri în care acest lucru poate fi implementat, dar pentru toate intențiile și scopurile și pentru a păstra exemplul relativ simplu, să presupunem că abonații se vor înscrie la editor cu ajutorul programului Observer Inregistreaza-te iar funcția acceptă o referință la abonat și fiecare abonat are o adresă Actualizați pe care editorul îl emite atunci când difuzează mesajul.
clasa MyPublisher / ** Lista de abonați care sunt înregistrați la acest editor * / abonați privat $; / ** * Responsabil pentru inițierea clasei și stabilirea listei de abonați. * / funcția publică __construct () $ this-> subscribers = array (); // constructor final / ** * adaugă subiectul primit la lista abonaților înregistrați * * @param array $ subject Subiectul de adăugat la lista de abonați * / public register function ($ subject) array_push ($ this- > abonați, subiectul $); // end register_subscriber / ** * Anunță toți abonații că sa întâmplat ceva prin apelarea metodei lor de "update" *. * / funcția publică notify_subscribers () pentru ($ i = 0; $ l < count( $this->abonați); $ i ++) $ current_subscriber = $ this-> abonați [$ i]; $ Current_subscriber-> actualizare (); // end for // end notify_subscribers // clasa de sfârșit
Codul de mai sus este la fel de simplu ca putem face:
Pentru cei care au mai multă experiență cu tehnicile orientate pe obiecte, atunci probabil veți vedea nevoia de a crea o interfață de clasă pentru Editor, dar acest lucru se află în afara scopului acestui tutorial.
Amintiți-vă, scopul este de a oferi doar un exemplu despre cum poate arata un simplu observator.
Crearea unui editor este într-adevăr doar jumătate din implementare. Ține minte, trebuie să avem ceva de fapt, știi tu, subscrie editorului să ia măsuri atunci când se întâmplă ceva.
Acesta este locul în care abonatul numit în mod corespunzător intră în joc.
class MySubscriber / ** Editorul căruia această clasă înregistrează * / privat $ publisher; / ** * Responsabil pentru inițializarea clasei și configurarea unei referințe la editorul * / funcția publică __construct () $ this-> publisher = new MyPublisher (); $ this-> publisher-> register ($ this); // constructor final / ** * Aceasta este metoda pe care editorul o cheamă când îi transmite mesajul. * / update public function () / ** Implementarea se bazeaza exclusiv pe orice doriti. * / // end update // clasa de sfârșit
Pe scurt, asta este. Observați mai sus că această punere în aplicare a Actualizați funcția nu este definită. Asta pentru că ne dă posibilitatea de a oferi un comportament unic acestei instanțe specifice.
Dar amintiți-vă, există o mulțime de cod în WordPress de bază care nu este orientat-obiect. În schimb, este procedural. Ca atare, implementarea unui model ca acesta variază puțin.
De exemplu, o analogie în WordPress ar fi ceva de genul:
Accentsconagua
function my_custom_subscriber ($ content) $ content = 'Acesta este continutul meu personalizat.' . conținut de $; returnați conținut $; // end my_custom_subscriber add_action ('the_content', 'my_custom_subscriber'); Observați că sintaxa este un pic diferită, dar în esență facem un lucru foarte asemănător:
my_custom_subscriber - și este înregistrată la continutul evenimentcontinutul funcționează focul, funcția personalizată va declanșa.Nimic prea complicat, sper.
Unul din scopurile din această serie nu este numai de a oferi câteva exemple de modele de proiectare și de implementare a acestora, dar acestea sunt deja în vigoare în sistemele existente.
În plus față de modelul condus de eveniment pe care l-am examinat mai sus, vom analiza, de asemenea, două modele care sunt comune, practice și extrem de utile în munca noastră de zi cu zi.
În mod specific, vom examina următoarele modele:
Evident, vorbind despre software-ul merge doar până acum, fără a vorbi despre diagrame și / sau de cod, așa că vom fi aruncați o privire la ambele din cele din următorul set de articole.
După cum puteți vedea, conceptul de modele de design nu este nimic teribil de complicat și există multe de câștigat prin utilizarea lor în munca noastră. Poate că cea mai mare provocare cu care se confruntă dezvoltatorii este folosirea modelelor de design pentru a folosi modele de design.
În schimb, este important să recunoaștem că există anumite situații în care modelele de design sunt aplicabile. Asta inseamna ca exista anumite probleme pentru care modelele de design sunt solutia perfecta. Experiența este, fără îndoială, cel mai bun profesor pentru a ști când să folosiți un model de design și când să nu îl utilizați.
În următoarele articole, sperăm că vom putea acoperi suficient teritoriu pentru a oferi două exemple solide de modele de design, când sunt aplicabile, cum să le folosească și cum ne pot ajuta în activitatea noastră viitoare.
