Share
În această serie, ne uităm la modelele de design și la modul în care le putem valorifica în avantajul nostru atunci când construim produse pe lângă WordPress.
Lucru frumos în ceea ce privește modelele de design este acela că acestea nu sunt limitate în mod explicit la teme sau plugin-uri - sunt la îndemână într-o varietate de scenarii diferite. Este pur și simplu o chestiune de a fi capabil să identificați care tipare sunt aplicabile anumitor scenarii.
În ultimul post, am revizuit Modelul Singleton. În acest articol, vom examina Modelul simplu de fabrică, care este deosebit de util atunci când aveți o serie de clase diferite, fiecare având un scop unic și rezolvă o problemă specifică.
În acest articol, 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 poate fi selectat pe baza anumitor criterii.
Simplul model de fabrică este de fapt derivat dintr-un model cunoscut sub numele de Metodă de fabricare a fabricii, care este o versiune puțin mai complicată a modelului pe care o vom revizui.
Potrivit Wikipedia, modelul Factory Method este definit după cum urmează:
Modelul metodei din fabrică este un model de design creator orientat pe obiecte pentru a implementa conceptul de fabrici și se ocupă de problema creării de obiecte (produse) fără a specifica exact clasa obiectului care va fi creat
Sună un pic cam complicat, nu-i așa??
Adevărul este că este de fapt un model de design cu adevărat puternic, dar ar fi nevoie de un articol mult mai lung pentru ao discuta și este puțin cam în afara scopului acestei serii.
Deci, așa cum am menționat, vom examina o versiune a modelului care este asociat puțin și ar trebui să să fie mai general aplicabilă proiectelor mai puțin complicate.
Înainte de a face acest lucru, să vină cu o definiție a Modelului simplu de fabrică:
Modelul Simple Factory returnează un anumit set de date sau o anumită clasă pe baza intrărilor sale.
Riscul de a face un joc de cuvinte, simplu, corect?
Adevărul este că mulți ingineri de software se referă la Fabrica Simplă mai mult ca un idiom decât un model plin de suflare; alții consideră acest lucru un model.
Pentru ceea ce merită, îl văd ca pe un model foarte simplu. Are un caz de utilizare specific care poate fi ușor de identificat când să îl folosiți pe parcursul dezvoltării pe care îl vom examina mai târziu în acest articol.
Indiferent, aduc acest lucru, astfel încât, dacă vedeți acest lucru ca un idiom (sau un model) folosit în diverse articole de pe Internet sau chiar în conversație, veți ști că dezvoltatorii în cauză se referă la aceeași strategie de programare - într-un mod diferit.
La fel ca modelele de design în proiecte specifice non-WordPress, cum ar fi aplicațiile mai mari, modelele de design oferă o modalitate încercată și adevărată de a rezolva o problemă comună.
Ajută la abstractizarea codului nostru, păstrarea proiectului nostru ușor de întreținut, ușor de citit și poate de fapt să ne ajute să păstrăm codul nostru sărac. Acest lucru poate duce la noi de fapt, avem mai mult fișiere în proiectul nostru, dar fiecare fișier ar trebui să aibă mai puține linii de cod.
Aceasta înseamnă că fiecare fișier ar trebui să aibă un scop specific, care ar trebui să fie clar, nu numai pentru noi, ci și pentru dezvoltatorii viitori.
Acum, înainte să ne aruncăm în diagrame, să vorbim despre clase și despre strategiile necesare pentru implementarea modelului real, vreau să menționez că vom lua o abordare simplă a acestui lucru.
Chestia este că cititorul acestui blog se întinde pe o gamă largă de experiențe - avem niște oameni care învață să scrie cod; alții care sunt veterani veterani.
Pentru a atrage majoritatea cititorilor, trebuie să găsim un echilibru. Deci, pentru cei dintre voi care s-au implicat cu inginerie software de ani de zile, acest lucru poate părea prea simplist; cu toate acestea, nu-l schimme - poate veți ridica ceva nou.
Pentru cei care sunteți începători sau chiar programatori intermediari, acordați o atenție deosebită ceea ce discutăm, deoarece poate oferi dividende în viitoare (sau chiar existente) lucrări.
Așa că imaginați-vă acest scenariu: Lucrați la o funcție care are un set de intrări - de obicei, un tip de șir sau un întreg unic - și aveți această lungă dacă / altceva declarație sau poate aveți acest mare comutator / caz declarație care continuă să crească odată cu creșterea numărului de proiecte.
Problema este că condiționările devin o durere de gestionat. De fapt, condiționările de caz sau blocurile de caz pot să ajungă la fel de mult ca o anumită funcție.
Aici intră Factory Simple. Ce putem face este să abrogem detaliile care se întâmplă în fiecare dintre condiționalități în propria clasă, făcând astfel mult mai ușor menținerea și menținerea codului mult mai slab.
Și acea este modelul simplu al fabricii.
Deci, aici sunt principalele caracteristici ale Modelului simplu de fabrică:
Nimic de asemenea complicată, nu? Sincer, cred că diagrama este un pic mai complicată decât principiile de joc. Oferă într-adevăr o mulțime de flexibilitate mai ales ori de câte ori doriți să introduceți un alt tip de utilizator ca un Editor sau ceva similar.
Notă: Aceasta este nu a fi confundat cu tipurile de utilizatori încorporate în WordPress. Acesta este doar un exemplu pentru a arăta cum ar arata modelul.
Acum, că am aruncat o privire la diagrama pentru model, să aruncăm o privire la codul sursă în acțiune. Mai jos, vom examina codul sursă pentru fiecare clasă și apoi voi oferi o descărcare la un demo complet documentat după discuție.
În primul rând, să examinăm clasa plugin. Amintiți-vă, acesta nu este altceva decât un prototip al aspectului modelului. Nu este același lucru ca un plugin WordPress complet dezvoltat.
fabrica = nou Simple_Factory (); funcția publică get_user ($ permisiune) return $ this-> factory-> get_user (permisiune $); ?>
Observați că plugin-ul este relativ simplu:
Accentsconagua
fabrica $ proprietate la o instanță a Simple_Factory get_user care returnează un utilizator bazat pe un tipVom vedea cum intră în joc după ce am examinat toate celelalte clase.
Utilizator este o clasă de bază abstractă care oferă un constructor de bază și o funcție abstractă care trebuie implementată de toate celelalte subclase.
rol = $ rol; funcția publică abstractă get_role (); ?>
Rețineți că această clasă este destinată a fi subclasată de o serie de alte clase, fiecare dintre care vom examina în detaliu momentan.
Următoarele patru clase sunt toate fișiere separate, fiecare dintre ele subclasă Utilizator clasa de bază. Am ales să le includem pe toate împreună, deoarece există o mică abatere de la implementarea lor reală, încât ar trebui să fie suficient de ușor să o urmezi.
rol = "Administrator"; funcția publică get_role () return $ this-> role; ?>
rol = "Reader"; funcția publică get_role () return $ this-> role; ?>
rol = "Voluntar"; funcția publică get_role () return $ this-> role; ?>
Ca de obicei, lasă-mi întrebări în comentariile; altfel, revizuiți codul, apoi asigurați-vă că vă citiți Fabrica simplă care este următoarea secțiune - legăturiază toate acestea împreună.
De asemenea, rețineți că tot acest cod va fi partajat la sfârșitul articolului împreună cu comentariile de cod care descriu exact ce se întâmplă.
Simple_Factory clasa este într-adevăr esența întregului model. Aici sunt toate deciziile luate și obiectele corespunzătoare sunt returnate.
Rețineți că Simple_Factory include clasa utilizator de bază și subclasele sale și apoi funcționează pentru a returna tipul corespunzător de utilizatori pe baza setului de permisiuni de intrare.
Deși ar trebui să fie un pic evident de acest punct în articol, Simple Factory Pattern oferă o serie de avantaje, mai ales dacă sunteți obișnuiți să lucrați cu condiționate mari.
În ansamblu, acesta este unul dintre modelele mele preferate pur și simplu pentru chestiunea organizării și specializării codurilor pe care le poate aduce la masă.
În cele din urmă, puteți verifica întregul cod sursă, completând documentația și instrucțiunile de instalare, pe GitHub utilizând acest link.
În acest moment, am analizat trei modele:
Această serie ar putea merge pentru o perioadă; cu toate acestea, cred că am acoperit suficient teren cel puțin pentru ca mulți dintre noi să înceapă cu modelele de implementare în munca noastră.
Deci, în ultimul articol din serie, vom recapitula ceea ce am învățat și vă voi recomanda și alte modele, scopul lor și alte câteva puncte de cercetare care ar trebui să vă continue să vă ajute să continuați să învățați despre modelele de design și avantajele lor nu numai în dezvoltarea WordPress, ci și dezvoltarea generală a software-ului.
