În cadrul acestei serii, analizăm semnificația modelelor de design și rolurile pe care le joacă în dezvoltarea WordPress.
În primul post din serie am făcut un sondaj la nivel înalt și chiar am revăzut modelul de observator pentru a vedea cum este posibilă înregistrarea diferitelor funcții sau obiecte cu anumite evenimente care apar în cadrul ciclului de viață al unei aplicații.
În acest post, unde se va arunca o privire la modelul Singleton.
Mai precis, vom analiza definiția modelului și modul în care funcționează, vom revedea o diagramă a arhitecturii modelului, vom acoperi un exemplu de cod pentru model, și apoi vom discuta despre avantajele modelului în legătură cu dezvoltarea WordPress.
Wikipedia definește Modelul Singleton după cum urmează:
În ingineria software, modelul singleton este un model de design care restricționează instanția unei clase la un obiect.
Poate că o modalitate mai simplă de a explica modelul este următoarea: Modelul Singleton asigură că o clasă poate avea doar o instanță și oferă o singură cale de a recupera o instanță de sine.
În ceea ce privește dezvoltarea temelor, eu personal nu văd o mare parte a unei utilizări pentru ea, dacă nu îmbinați un tip de clasă sau bibliotecă ajutător cu tema dvs.; cu toate acestea, dacă construiți pluginuri, atunci acest lucru poate fi extrem de util.
De acum, există într-adevăr doar o mână de moduri de a instanțiate plugin-uri (cu excepția widget-uri - acesta este un alt subiect) în cadrul WordPress:
$ GLOBALS
colectare, dar acest lucru poate fi periculos, deoarece ar putea să distrugeți ceva deja existent sau să faceți colecția inutil mai mareNici unul dintre cele de mai sus nu este deosebit bun (deși ați putea face un caz că toate acestea funcționează).
Cu toate acestea, ne pasă mai mult decât să luăm ceva la lucru, nu? Vrem ca aceasta să funcționeze și dorim o soluție elegantă a problemei. Acesta este locul unde modelele de design - mai exact, modelul Singleton - intră în joc.
În primul rând, să aruncăm o privire la o diagramă a modelului Singleton. Consultați diagrama de mai jos, după care vom vorbi despre specificul după imagine:
Deci, aici sunt caracteristicile cheie ale Modelului Singleton:
get_instance
care este folosit pentru a returna o instanță a claseiNimic de asemenea complicat, dar cred că revizuirea codului pentru modelul Singleton merge mult în a face un pic mai clar, așa că hai să facem asta acum:
clasa Foo / * -------------------------------------------- * * Atribute * ---------------------------------------------- * / / ** Se referă la o singură instanță a acestei clase. * / static privat $ instance = null; / * -------------------------------------------- * * Constructor * -------------------------------------------- * / / ** * Creează sau returnează o instanță a acestei clase. * * @return Foo O singură instanță a acestei clase. * / funcția statică publică get_instance () if (null == auto :: $ instanță) self :: $ instance = new self; întoarcere de sine :: $ instanță; // end get_instance; / ** * Inițializează pluginul prin setarea funcțiilor de localizare, filtre și administrare. * / funcția privată __construct () // constructor final / * ----------------------------------- --------- * * Funcții * ------------------------------------- ------- * / // clasa de clasă Foo :: get_instance ();
Evident, a fost mult de cod rămase din clasa de mai sus, dar principiile modelului rămân.
Observați că avem o variabilă instanță privată, statică, care este folosită pentru a se referi la această clasă. Mai exact, este setat în get_instance
în timp ce constructorul a fost marcat ca fiind privat.
În mod obișnuit, atunci când instanŃează clasele, constructorul este funcŃia numită de fiecare dată când iniŃializăm clase; cu toate acestea, în acest caz, constructorul este marcat ca privat.
Deci ce dă?
Observați că avem un public get_instance
funcționează chiar deasupra constructorului. Această funcție verifică literal pentru a vedea dacă variabila statică este nul
și, dacă da, creează o nouă instanță a clasei (pe care o poate face din moment ce este în contextul clasei); în caz contrar, returnează instanța curentă.
Acesta este modul în care nu se creează decât o singură instanță a unei clase.
În cele din urmă, rețineți că instanțiăm clasa nu cu standardul nou
cuvânt cheie, dar prin apelarea get_instance
. Nu numai asta, ci și referințe viitoare la clasă, folosind aceeași metodă.
De exemplu, să spunem că lucrați într-un alt șablon și că trebuie să apelați o funcție - să zicem bar()
- care există în plugin-ul dvs. În acest caz, ați face astfel:
$ foo = Foo :: get_instance (); $ Foo-> bar ();
Destul de îngrijit, nu-i așa??
În ciuda faptului că am acoperit modelul Singleton din punct de vedere arhitectural și practic, nu am vorbit de avantajele modelului.
In general vorbind:
Poate că cel mai mare dezavantaj din utilizarea modelului este lipsa de claritate că pluginul utilizează de fapt modelul. Dacă cineva încearcă să instanțizeze clasa, instanțiarea va eșua, deoarece nu există constructor public.
Ca atare, documentația este esențială.
Indiferent dacă le-ați văzut înainte sau aceasta este prima dvs. incursiune în modelele de design, modelul Singleton este, fără îndoială, cel mai simplu model de design acolo. Este ușor de implementat și oferă o sursă importantă de funcționalitate atunci când este implementată corect, mai ales în ceea ce privește aplicațiile web.
În următoarea postare vom examina un alt model - modelul simplu de fabrică - care este util atunci când aveți un număr de clase, fiecare având un scop unic și care va fi necesar pe baza anumitor criterii de intrare.