Partea 4 – WordPress și programare orientată pe obiecte: Un exemplu WordPress – Design

În acest moment, avem cerințe clar definite, așa cum au fost descrise în partea 3 a acestei serii (verificați-l aici dacă ați ratat-o).

Acum este momentul să începem să ne gândim la designul noului nostru și îmbunătățit plugin!

Dorim să vă reamintim că acest pas vă poate dura mult timp atunci când îl încercați în propriile proiecte. Probabil că nici de prima dată nu vei face totul bine. Sunt șanse să veniți cu un design, să începeți să îl implementați și apoi să realizați că trebuie să vă întoarceți și să vă regândiți abordarea.

Totuși, merită pe deplin efortul, așa că luați-vă cât timp este necesar pentru a face totul corect. Un proiect bine structurat va facilita menținerea și extinderea acestuia și chiar reutilizarea codului său în alte proiecte, astfel încât pe termen lung este o bună utilizare a timpului.

În continuare, ne vom concentra asupra unor părți cheie ale pluginului și vom discuta despre modul în care am venit cu designul nostru.

Disecarea paginii de setări

Să aruncăm o privire mai atentă la pagina de administrare a pluginului.

Veți observa că există un titlu („Setări Limitare încercări de conectare”), mai multe secțiuni care conțin unele câmpuri și un buton „Modificare opțiuni” în partea de jos a paginii.

Fiecare secțiune constă dintr-un titlu, cum ar fi „Statistici”, și câteva câmpuri.

Fiecare câmp are un titlu în stânga, iar restul conținutului în partea dreaptă. Există câmpuri de text, butoane radio și casete de selectare și, unele dintre ele, precum „Total Lockouts”, afișează doar informații și nu pot fi modificate direct de utilizatorul administrator.

Unele câmpuri includ și o descriere, cum ar fi câmpul „Conexiune la site”, dar nu toate.

Având în vedere cele de mai sus, trebuie să-l descompunem în bucăți conceptuale care mai târziu vor deveni cursuri.

API-ul WordPress Settings ne permite să înregistrăm pagini de setări, secțiuni din acele pagini și câmpuri din secțiuni:

Pagini → Secțiuni → Câmpuri

Ne-am gândit, de ce să nu mai adăugăm un „strat”, Elementele, pentru a face pluginul nostru mai ușor de extins în viitor.

Pagini → Secțiuni → Câmpuri → Elemente

Deci, Paginile și Secțiunile sunt ceea ce am explicat deja mai sus, iar Câmpurile vor conține elemente de orice tip de conținut în partea dreaptă.

Luând în considerare toate aceste tipuri diferite de elemente, am optat pentru o clasă Element și mai multe clase, extinzând-o, pentru casetele de selectare, butoanele radio, numerele etc. care vor reda rezultate diferite.

Este posibil să fie nevoie, de asemenea, să adăugăm mai multe pagini și secțiuni în viitor. Deci, este probabil să fie nevoie să extindem aceste clase de pagini și secțiuni de administrare.

Același lucru este valabil și pentru câmpuri. Clasele pentru „Blocari totale”, „Blocari active” etc. vor extinde aceeași clasă (părinte).

Iată o imagine simplificată care demonstrează aceste relații:

Desigur, nu toate „componentele” sunt incluse în diagramă.

O structură ca aceasta face pluginul mai ușor de extins; putem adăuga cu ușurință un câmp, un element sau o secțiune dacă este nevoie. Vom putea adăuga cu ușurință mai multe componente - câmpuri, elemente sau secțiuni - prin crearea de noi clase copii, fără a fi nevoie să le modificăm pe cele existente.

Gândirea și abstracția

Acum este un moment minunat să începeți să vă gândiți la ce fac diferitele componente ale pluginului nostru. În faza de proiectare, nu trebuie să intrăm în multe detalii despre cum funcționează ceva.

De exemplu, luați în considerare toate elementele, tabelele, statisticile și aproape orice altceva care va fi afișat utilizatorului. Ele ar putea fi componente separate, fără nimic în comun, dar toate vor face în cele din urmă unele rezultate. Prin urmare, unele funcționalități vor fi comune pentru componentele care altfel nu sunt complet legate. Desigur, acest lucru se extinde și la restul componentelor noastre.

În imaginea de mai sus, vedem cum o interfață UI este implementată de mai multe clase.

Acordați atenție faptului că interfața UI este implementată de clasele Statistics, Lockout Logs, Table și Element, care sunt denumite clase părinte . Nu este nevoie ca clasele Radio/Number/Checkbox Element să implementeze interfața direct, deoarece moștenesc toate interfețele din clasa lor părinte. Cu toate acestea, o clasă copil ar putea suprascrie o metodă a clasei sale părinte.

Din moment ce știm că pluginul nostru se va ocupa de setări, putem presupune cu siguranță că le vom citi și scrie valorile. Adică, posibilitatea de a obține , a seta și a elimina opțiuni.

Toate aceste acțiuni vor fi grupate într-o clasă. Probabil ne vom stoca opțiunile în baza de date WordPress sau ceva de genul ăsta. Deocamdată, nu trebuie să ne preocupe cum sau unde ne vom stoca datele.

Putem păstra abstractizarea opțiunilor de obținere/setare/eliminare în mintea noastră, simplificând lucrurile din punct de vedere conceptual și continuă să ne proiectăm pluginul.

Fișierul principal de plugin

Aici, vom oferi câteva informații despre plugin pentru WordPress prin comentariul din antet și vom efectua unele inițializare. Ne vom organiza codul, împachetând totul într-o clasă mică.

În funcție de modul în care clasele pluginului nostru vor funcționa împreună, clasa principală va trebui să instanțieze majoritatea dintre ele. Din câte știm, acestea vor include clase legate de opțiuni, pagini de administrare, reîncercări și blocări.

Clase potențiale

Ne-am luat ceva timp să încercăm să ne dăm seama de ce cursuri vom avea nevoie și am ajuns cu o listă după cum urmează:

• Reîncercări
• Blocări
• Cookie-uri
• Mesaje de eroare
• Notificări prin email
• Notificări ale administratorului
• Butoane
• Jurnalele de blocare
• Blocări active/totale
• adresa IP

Rețineți că nu există o singură modalitate „corectă” de a vă structura pluginul. Ca și în majoritatea lucrurilor în dezvoltarea de software, există mai multe modalități, la fel de valide, de a rezolva o problemă.

În secțiunea „General”, de exemplu, relațiile dintre clasele noastre ar arăta astfel:

Secțiunea „Statistici” va fi similară cu aceasta:

În cele din urmă, „Jurnalele de blocare” vor fi foarte asemănătoare cu „Statistici”:

Concluzie

Până acum ne-am definit cerințele și ne-am gândit la un design pentru pluginul nostru nou și îmbunătățit. Am explicat cum am venit cu structura noastră și am furnizat, de asemenea, câteva diagrame simple care arată modul în care clasele noastre vor fi legate între ele.

Faceți clic aici pentru a citi partea 5 din seria noastră de programare orientată pe obiecte

Vezi si

• WordPress și programarea orientată pe obiecte – O prezentare generală
• Partea 2 – WordPress și programarea orientată pe obiecte: un exemplu din lumea reală
• Partea 3 – WordPress și programare orientată pe obiecte: Un exemplu WordPress – Definirea domeniului de aplicare