V-ați întrebat vreodată ce modele de design sunt? În acest articol, voi explica de ce modelele de design sunt importante și vă va oferi câteva exemple, în PHP, despre momentul și de ce ar trebui folosite.
Modelele de proiectare sunt optimizate, soluții refolosibile la problemele de programare pe care le întâlnim în fiecare zi. Un model de design nu este o clasă sau o bibliotecă pe care să putem conecta pur și simplu la sistemul nostru; este mult mai mult decât atât. Este un șablon care trebuie implementat în situația corectă. Nu este vorba nici de limbă. Un model de design bun ar trebui să fie implementabil în majoritatea limbilor, dacă nu în toate limbile, în funcție de capacitățile limbii. Cel mai important, orice tip de design poate fi o sabie cu două tăișuri - dacă este implementată într-un loc greșit, poate fi dezastruoasă și poate crea multe probleme pentru dvs. Cu toate acestea, implementat în locul potrivit, la momentul potrivit, acesta poate fi salvatorul dvs..
Există trei tipuri de bază de modele de design:
Structural modelele se referă, în general, la relațiile dintre entități, făcând astfel mai ușoară colaborarea acestor entități.
Creational modelele oferă mecanisme de instanțiere, facilitând crearea obiectelor într-un mod care să se potrivească situației.
Comportamental modelele sunt utilizate în comunicările între entități și fac mai ușoară și mai flexibilă pentru aceste entități să comunice.
Modelele de proiectare sunt, în principiu, soluții bine gândite la problemele de programare. Mulți programatori au întâmpinat aceste probleme înainte și au folosit aceste "soluții" pentru a le remedia. Dacă întâmpinați aceste probleme, faceți din nou o soluție atunci când puteți folosi un răspuns deja dovedit?
Să ne imaginăm că v-ați dat responsabilitatea de a crea o modalitate de a îmbina două clase care fac două lucruri diferite bazate pe situație. Aceste două clase sunt puternic utilizate de sistemul existent în diferite locuri, ceea ce face dificilă eliminarea acestor două clase și modificarea codului existent. Pentru a adăuga acest lucru, schimbarea codului existent necesită, de asemenea, testarea oricărui cod modificat, deoarece aceste tipuri de modificări, într-un sistem bazat pe componente diferite, introduc aproape întotdeauna noi erori. În loc să faceți acest lucru, puteți implementa o variantă a tiparului de strategie și a modelului de adaptor, care poate gestiona cu ușurință aceste tipuri de scenarii.
_context = context context; funcționarea funcției publice1 () if ($ this -> _ context == "context_for_class_one") $ this -> _class_one-> operation1_in_class_one_context (); altceva ($ this -> _ context == "context_for_class_two") $ this -> _ class_two-> operation1_in_class_two_context ();
Destul de simplu, nu? Acum, să examinăm mai atent strategia de strategie.
strategie este un model de design comportamental care vă permite să decideți ce curs de acțiune trebuie să efectueze un program, pe baza unui context specific în timpul rulării. Încadrați doi algoritmi diferiți în două clase și decideți la timpul de execuție care strategie cu care vrei să mergi.
În exemplul nostru de mai sus, strategia se bazează pe orice $ context variabila era la momentul în care instanța a fost instanțiată. Dacă îi dați contextul pentru class_one, va folosi clasa_one și invers.
Imaginați-vă că în prezent dezvoltați o clasă care poate actualiza sau crea un nou record de utilizatori. Încă mai are nevoie de aceleași intrări (nume, adresă, număr mobil etc.), dar, în funcție de o anumită situație, trebuie să utilizeze diferite funcții atunci când se actualizează și creează. Acum, probabil că ați putea folosi doar un altul pentru a realiza acest lucru, totuși, dacă ar trebui să utilizați această clasă într-un alt loc? În acest caz, va trebui să rescrieți aceeași declarație if-else din nou. Nu ar fi mai ușor să specificați contextul?
Acum, modelul de strategie "obișnuit" implică încapsularea algoritmilor în altă clasă, dar în acest caz o altă clasă ar fi risipă. Amintiți-vă că nu trebuie să urmați exact șablonul. Variațiile funcționează atâta timp cât conceptul rămâne același și rezolvă problema.
Modelul adaptorului
Imagine de la http://www.uxcell.commodel de adaptor este un model de design structural care vă permite să reprofilați o clasă cu o interfață diferită, permițându-i să fie folosită de un sistem care utilizează diferite metode de apelare.
Acest lucru vă permite, de asemenea, să modificați unele dintre intrările primite de la clasa client, făcându-l compatibil cu funcțiile adaptorului.
Cum pot folosi acest lucru?
Un alt termen referitor la o clasă de adaptor este a învelitoare, care practic vă permite să "înfășurați" acțiunile într-o clasă și să reutilizați aceste acțiuni în situațiile corecte. Un exemplu clasic ar putea fi atunci când creați o clasă de domenii pentru clase de tabele. În loc să apelați diferite clase de tabele și să apelați funcțiile lor unul câte unul, puteți încapsula toate aceste metode într-o singură metodă utilizând o clasă de adaptor. Acest lucru nu numai că vă va permite să refolosiți acțiunile pe care le doriți, dar vă împiedică să rescrieți codul dacă trebuie să utilizați aceeași acțiune într-un alt loc.
Comparați aceste două implementări.
Abordarea fără adaptor
CreateOrUpdate (// intrări); $ profil = Profil nou (); $ profile-> CreateOrUpdate (// intrări);Dacă ar fi trebuit să facem din nou acest lucru într-un loc diferit sau chiar să reutilizăm acest cod într-un proiect diferit, ar trebui să introducem totul peste tot.
Mai bine
Aceasta se opune a face ceva de genul acesta:
NewAccount (// intrări);În această situație, avem o clasă de wrapper, care ar fi clasa domeniului cont:
CreateOrUpdate (// subset de intrări); $ profil = Profil nou (); $ profile-> CreateOrUpdate (// subset de intrări);În acest fel, puteți să vă utilizați din nou domeniul dvs. de cont ori de câte ori aveți nevoie de el - plus, veți putea încheia și alte clase în cadrul clasei dvs. de domeniu.
Metoda de fabricare a fabricii
Imagine de la http://www.lankanewspappers.commetoda fabricii modelul este un model de design creator care se comportă exact așa cum se pare: este o clasă care acționează ca o fabrica de instanțe de obiecte.
Scopul principal al acestui model este de a incapsula procedura de creatie care poate include diferite clase intr-o singura functie. Prin furnizarea contextului corect la metoda din fabrică, va fi capabil să returneze obiectul corect.
Când pot folosi acest lucru?
Cel mai bun timp pentru a utiliza modelul metodei din fabrică este atunci când aveți mai multe variante diferite ale unei singure entități. Să presupunem că aveți o clasă de butoane; această clasă are variații diferite, cum ar fi ImageButton, InputButton și FlashButton. În funcție de locație, poate fi necesar să creați diferite butoane - aici puteți utiliza o fabrică pentru a crea butoanele pentru dvs.!
Să începem prin crearea a trei clase:
_html; clasa ImageButton extinde butonul protejat $ _html = "..."; // Aceasta ar trebui să fie orice HTML doriți pentru butonul bazat pe imagine class InputButton extinde butonul protejat $ _html = "..."; // Aceasta ar trebui să fie ceea ce doriți HTML pentru butonul dvs. normal (); clasa FlashButton extinde butonul protejat $ _html = "..."; // Aceasta ar trebui să fie orice HTML doriți pentru butonul dvs. bazat pe flashAcum, putem crea clasa fabricii noastre:
Putem folosi acest cod ca atare:
$ buttons = array ('imagine', 'intrare', 'flash'); foreach ($ butoane ca $ b) echo ButtonFactory :: createButton ($ b) -> getHtml ()Rezultatul ar trebui să fie codul HTML al tuturor tipurilor de butoane. În acest fel, veți putea să specificați ce buton să creați în funcție de situație și să refolosiți condiția.
Modelul Decoratorului
Imagine de la http://www.decoratorsdarlington.co.ukdecorator modelul este un model de design structural care ne permite să adăugăm un comportament nou sau suplimentar unui obiect în timpul executării, în funcție de situație.
Scopul este de a face ca funcțiile extinse să poată fi aplicate la o anumită instanță și, în același timp, să poată crea încă o instanță originală care nu are noile funcții. De asemenea, permite combinarea mai multor decoratori cu o singură instanță, astfel încât să nu fiți blocați cu un decorator pentru fiecare instanță. Acest model este o alternativă la subclasarea, care se referă la crearea unei clase care moștenește funcționalitatea dintr-o clasă parentală. Spre deosebire de subclasarea, care adaugă comportamentul la momentul compilării, "decorarea" vă permite să adăugați un comportament nou în timpul runtime-ului, dacă situația îl solicită.
Pentru a implementa modelul de decorator, putem urma acești pași:
- Subclasa clasa originală "Component" într-o clasă "Decorator"
- În clasa Decorator, adăugați un pointer Component ca câmp
- Transmiteți o componentă constructorului Decorator pentru a inițializa indicatorul Component
- În clasa Decorator, redirecționați toate metodele "Component" la cursorul "Component" și
- În clasa Decorator, înlocuiți orice metodă Componente a cărei comportare trebuie modificată
Pași fideli http://en.wikipedia.org/wiki/Decorator_pattern
Când pot folosi acest lucru?
Cel mai bun loc pentru a utiliza modelul de decorator este când aveți o entitate care trebuie să aibă un comportament nou numai dacă situația o cere. Să presupunem că aveți un element de legătură HTML, un link de logout, pe care doriți să faceți lucruri ușor diferite în funcție de pagina curentă. Pentru aceasta, putem folosi modelul de decorator.
În primul rând, să stabilim diferitele "decorațiuni" de care avem nevoie.
Odată ce ne-am stabilit decorațiile, putem începe să le programăm.
_html = "Deconectare"; funcția publică setHtml ($ html) $ this -> _ html = $ html; public function render () echo $ this -> _ html; clasa LogoutLinkH2Decorator extinde HtmlLinks protejat $ _logout_link; funcția publică __construct ($ logout_link) $ this -> _ logout_link = $ logout_link; $ This-> setHtml (“"$ this -> _ html."
") funcția publică __call ($ name, $ args) $ this -> _ logout_link -> $ nume ($ args [0]); clasa LogoutLinkUnderlineDecorator extinde HtmlLinks protected $ _logout_link; public function __construct ($ logout_link) $ acest -> _ logout_link = $ logout_link; $ this-> setHtml (""$ this -> _ html.""); funcția publică __call ($ name, $ args) $ this -> _ logout_link -> $ name ($ args [0]); logoutLinkStrongDecorator extinde HtmlLinks protected $ _logout_link; public function __construct ($ logout_link) $ acest -> _ logout_link = $ logout_link; $ this-> setHtml (""$ this -> _ html.""); funcția publică __call ($ name, $ args) $ this -> _ logout_link -> $ nume ($ args [0]);
Atunci ar trebui să putem să o folosim așa:
$ logout_link = nou LogoutLink (); dacă ($ is_logged_in) $ logout_link = nou LogoutLinkStrongDecorator ($ logout_link); dacă ($ in_home_page) $ logout_link = nou LogoutLinkH2Decorator ($ logout_link); altceva $ logout_link = nou LogoutLinkUnderlineDecorator ($ logout_link); $ logout_link-> render ();
Putem vedea aici cum putem combina mai mulți decoratori dacă avem nevoie de ele. Deoarece toți decoratorii folosesc __apel magie, putem numi în continuare metodele funcției inițiale. Dacă presupunem că suntem în prezent în interiorul paginii principale și logat, rezultatul HTML ar trebui să fie:
Deconectare
Singleton modelul de proiectare este un model de design creator care vă asigură că aveți o singură instanță dintr-o anumită clasă în durata runtimei și oferă un punct global de acces la instanța unică.
Acest lucru face mai ușor să se stabilească un punct de "coordonare" pentru alte obiecte care utilizează și instanța singleton, deoarece variabilele singleton vor fi întotdeauna aceleași pentru orice se numește.
Dacă trebuie să treci o instanță specifică de la o clasă la alta, poți folosi modelul singleton pentru a evita să treci instanța prin constructor sau argument. Imaginați-vă că ați creat o clasă de sesiuni, care simulează matricea globală $ _SESSION. Deoarece această clasă va trebui doar să fie instanțiată o singură dată, putem implementa un model singleton cum ar fi:
Procedând astfel, putem accesa instanța de sesiune din diferite părți ale codului nostru, chiar și în diferite clase. Aceste date vor persista pe parcursul tuturor apelurilor getInstance.
Concluzie
Există multe modele de design mai multe pentru a studia; în acest articol, am subliniat doar unele dintre cele mai proeminente pe care le folosesc la programare. Dacă sunteți interesat să citiți despre celelalte modele de design, pagina Wikipedia Design Patterns are o mulțime de informații. Dacă acest lucru nu este de ajuns, puteți verifica oricând modelele de design: Elemente ale software-ului orientat pe obiecte, care este considerat a fi unul dintre cele mai bune cărți de model de design disponibile.
Un ultim lucru: când folosiți aceste modele de design, always asigurați-vă că încercați să rezolvați problema corectă. După cum am menționat anterior, aceste modele de design sunt o sabie cu două margini: dacă sunt folosite într-un context greșit, ele pot face lucrurile să se înrăutățească; dar dacă sunt folosite corect, ele devin indispensabile.
Dacă ați găsit acest tutorial util, de ce nu verificați gama de scripturi PHP de pe Envato Market. Există mii de scripturi utile care vă pot accelera dezvoltarea și vă pot ajuta să obțineți rezultate finale mai bune. Puteți găsi sisteme de rezervare, formulare de contact AJAX, sisteme de newsletter și multe altele.
Script-uri PHP pe Envato Market