Utilizarea spațiilor de nume și Autoloading în Pluginurile WordPress, Partea 3

În acest tutorial, vom face o pauză de la scrierea codului și vom examina ce spații de nume și autoreglare din PHP sunt, cum funcționează și de ce sunt benefice. Apoi ne vom pregăti pentru a încheia această serie implementând-o în cod.

Dacă nu sunteți prins de tot ceea ce am abordat în seria acestui punct, vă recomand să reveniți și să revizuiți ceea ce am acoperit până acum. Cel puțin, revizuiți articolul precedent, deoarece acesta va pune bazele a ceea ce vom vorbi în următoarele două articole.

Acum că sunteți prinși, sunteți conștienți de plugin-ul pe care lucrăm, de ceea ce face și de cum funcționează. Mai mult, trebuie să aveți un mediu de dezvoltare local care să vă permită să lucrați cu codul sursă. Dacă nu, iată o scurtă descriere a tot ceea ce aveți nevoie:

• Un mediu de dezvoltare locală care include PHP 5.6.20, serverul web Apache și un server de bază de date MySQL.
• Un director din care WordPress 4.6 este găzduit.
• Un editor de text sau un IDE la alegerea dvs., pe care îl utilizați pentru scrierea unui plugin.
• O cunoaștere activă a API-ului WordPress Plugin.

Presupunând că aveți toate cele instalate, configurate și gata pentru a merge împreună cu cea mai recentă versiune a pluginului, atunci suntem gata să reluăm discuția noastră cu privire la modulele de plugin, autoloading și pluginurile WordPress.

Pe spații de nume și autoloading

Pentru cei care au lucrat în alte limbi moderne de programare, este posibil să fiți familiarizați cu conceptul de spații de nume. Dar chiar dacă ați lucrat cu PHP, este puțin probabil că le-ați văzut mult, cel puțin în contextul WordPress.

Pentru aceia dintre voi nu au auzit de ei sau de cine avea au auzit de ele, dar nu le-au folosit, de aceea este vorba despre acest articol special. Mai precis, vom vorbi despre spații de nume și autoloading și apoi, în tutorialul următor, vom vedea cum se potrivesc toate împreună.

Adică, vom prelua munca pe care am făcut-o cu plugin-ul nostru până acum și apoi o vom actualiza astfel încât să folosească spații de nume și autoloading. Acest lucru vă va oferi o înțelegere practică a conceptelor, precum și câteva instrumente noi pentru a vă adăuga repertoriul de dezvoltare atunci când lucrați la următorul proiect.

Care sunt spațiile de nume?

Ca și în majoritatea tutorialelor mele, îmi place să ofer definiția formală și apoi să o împart în termeni mai conversativi. Manualul PHP definește spațiile de nume cum ar fi:

În cea mai largă definiție, spațiile de nume reprezintă o modalitate de încapsulare a elementelor. 

Asta nu ne ajută neapărat mult, nu-i așa? S-ar putea argumenta că clasele fac același lucru permitând atât atributele, cât și funcțiile să poată fi generalizate ca elemente. Dar manualul continuă:

Nivelele de nume ale domeniului PHP oferă o modalitate de grupare a claselor, interfețelor, funcțiilor și constantelor asociate.

E un pic mai clar, nu? Aceasta înseamnă că atunci când avem un grup de clase conexe, le putem grupa împreună în același director sau în directoare similare pe sistemul de fișiere, dar nu există nici o modalitate de a ști că prin examinarea codului.

Spațiile de nume ne dau posibilitatea de a face asta.

Gândiți-vă la acest lucru: Imaginați-vă că aveți un set de funcționalități legate de colaborarea cu CSV-urile. 

• Poate că aveți o clasă responsabilă pentru citirea unui fișier CSV, parsarea conținutului și citirea conținutului într-o matrice. 
• Apoi, aveți o clasă care este responsabilă pentru luarea acelei matrice și scrierea datelor în baza de date pe baza conținutului matricei. 
• După aceea, există o clasă responsabilă pentru citirea acestor opțiuni ori de câte ori un obiect terță parte sau o altă zonă din cod trebuie să citească datele citite, analizate și salvate mai devreme în execuția proiectului.

Toate aceste funcționalități ar trebui să cuprindă mai multe clase. În funcție de modul în care codul orientat pe obiecte este soluția dvs., este posibil să aveți și un set de interfețe implementate de clasele dvs. În plus, clasele pot fi organizate într-un / csv director, dar defalcate și mai mult în propriile subdirectoare. 

• /citit
• /scrie

Poate că ați opta să organizați structura un pic diferit, dar pentru a menține discuția cât mai simplă, am crezut că acest lucru ar avea sens. Deci, poate că interfața de clasă ar locui în rădăcina / csv director, cititorul ar locui în /citit directorul și clasele responsabile pentru scrierea datelor în baza de date s-ar afla în /scrie director.

Nimic pe care l-am spus până acum nu este obișnuit în ceea ce privește modul în care ne putem organiza dosarele. Dar aici intră în joc spațiile de nume. 

Mai exact, dacă am reușit să organizăm clasele noastre, astfel încât acestea să fie și cartografiate la locația lor fizică în sistemul de fișiere?

Gândiți-vă în acest fel: Să presupunem că pluginul dvs. este numit Acme CSV, iar clasele de mai sus sunt organizate în directoarele și subdirectoarele lor și așa mai departe. Ce ar putea arăta locurile de nume pentru aceste clase și cum ar fi ele declarate în cadrul proiectului?

Uitați-vă la ceea ce vom numi Parser clasă. Această clasă se află în / Csv / citire.

Și apoi să spunem că avem clasa noastră care scrie date în baza de date:
În cele din urmă, să vedem ce este spațiul de nume pentru clasă, care citește date din baza de date:
Nimic complicat, nu? Deși standardul de mai sus nu este modul în care vă avea pentru a vă organiza fișierele, îmi place să încerc să-mi hartă orele la locația pe disc. Îi face mai ușor să se refere la acestea în activitatea viitoare. 
În acest moment, nu este nimic mai mult de văzut dincolo de declararea unui tip de organizare a clasei dvs. în partea de sus a fișierelor. Dar când începeți să includeți autoloading, acest lucru se schimbă.
Un cuvânt pe pachete și subpachete
Înainte de a vorbi despre autoloading, totuși, vreau să fac o scurtă aplecare asupra @pachet și @subpackage etichete pe care de obicei suntem obișnuiți să le vedem în comentariile despre fișiere.
De exemplu, probabil ați văzut ceva de genul acesta în legătură cu codul de mai sus:
Dar când vă referiți la documentația phpDocumentor, veți vedea următoarele despre @subpackage:
Această etichetă este considerată depreciată și poate fi eliminată într-o versiune viitoare a phpDocumentor. Se recomandă să utilizați capacitatea etichetei @package de a oferi mai multe nivele.
Asa de @subpackage este depreciat, ceea ce înseamnă că probabil nu ar trebui să ne mai deranjez să îl folosim. Dar despre @pachet etichetă?
Eticheta @package este folosită pentru a clasifica Elementele Structurale în subdiviziuni logice.
Suportul pentru cuiburi multiple se află acum numai în eticheta respectivă. E bine de știut, nu? Aceasta înseamnă că codul pe care îl vedem mai sus poate fi scris în felul următor:
Sigur, este un exemplu simplu, dar are scopul. Am menționat acest lucru pentru că @subpackage este încă o altă etichetă pe care o vedem deseori în PHP bazată pe WordPress pe care trebuie să o evităm dacă vrem să adoptăm standarde mai noi.
Ce este Autoloading?
Cu asta a spus, să revenim la subiectele primare de la mână. Din moment ce am acoperit spațiile de nume, să ne uităm la autoloading. Conform manualului PHP:
Mulți dezvoltatori care scriu aplicații orientate pe obiecte creează un fișier sursă PHP pe definiție de clasă. Una dintre cele mai mari neplăceri este să scrie o listă lungă de necesare include la începutul fiecărui scenariu (câte unul pentru fiecare clasă).
Nu s-ar putea spune nimic mai bine, nu-i așa? Cu toate acestea, nu explică cu adevărat ce este autoloading. Pur și simplu explică problema pe care o poate rezolva.
În PHP 5, acest lucru nu mai este necesar ... [suporta încărcarea] clase și interfețe care urmează să fie încărcate automat dacă acestea nu sunt definite în prezent.
Sună fantastic, nu? Dar există o avertizare și o vom explora detaliat în următorul tutorial. Dar până atunci, aici este: Pentru a obține această funcționalitate, trebuie să implementăm o funcție care știe unde să căutăm fișierele de încărcat și cum să analizăm structura directoarelor acelor fișiere.
Se pare că este plictisitor, iar unele cazuri ar putea fi, dar dacă aveți o metodă consecventă de organizare a lucrării, codul autoloading poate fi portabil. Adică puteți să luați funcția pe care o scrieți, să o abandonați în orice proiect bazat pe PHP și să fiți gata să faceți totul.
Dar acest tutorial nu este despre scrierea codului. Este vorba despre acoperirea ideii din spatele conceptelor codului pe care le vom implementa în tutorialul următor.
De ce este ceva relevant?
În funcție de cine vă cereți, puteți vizualiza spațiile de nume și autoloading ca noi în PHP. Pentru unii, acest lucru este adevărat. Pentru alții, ei lucrează cu aceste două concepte pentru o vreme.
Unul dintre lucrurile despre WordPress care îl pot reține de la adoptarea noilor caracteristici ale PHP este angajamentul său față de compatibilitatea înapoi. Acest lucru nu este neapărat un lucru bun sau un lucru rău - este un atribut al aplicației.
Dar, deoarece WordPress are o versiune minimă de PHP pe care rulează, caracteristicile limbajului mai nou nu sunt întotdeauna adoptate. Și atunci când această versiune minimă este adoptat, este nevoie de puțin timp dezvoltatorii WordPress pentru a începe să utilizeze aceste caracteristici în codul lor.
Și nu e un lucru rău. Pe scurt, dezvoltatorii țin pasul cu aplicația în ritmul în care se maturizează.
Dar, pe măsură ce WordPress continuă să meargă înainte sau dacă aveți control asupra mediului în care rulează proiectul dvs., este posibil să fiți interesat să adoptați câteva dintre caracteristicile limbii pe care nu ați știut anterior că ați existat sau pe care nu ați cunoscut-o anterior.
Păcatele de nume și autoloading sunt două caracteristici puternice ale limbajului care merg foarte mult în a face codul mai ușor de citit, mai organizat și chiar mai ușor de întreținut. Deci, dacă totuși le-ați folosit în oricare dintre lucrările dvs. în WordPress, mai ales dacă lucrați cu pluginurile WordPress, vă recomand să vă gândiți să faceți acest lucru.
Concluzie
Spațiul de nume ne dă posibilitatea de a organiza codul nostru într-un mod care face mult mai ușor gruparea logică a claselor conexe. Mai mult, autoloadingul oferă codului nostru o mai mare lizibilitate prin reducerea numărului de include, include_once, necesita, sau require_once declarații pe care trebuie să le folosim.
Acest lucru face ca codul sursă pe care îl scriem să fie mai clar în sensul că se concentrează exclusiv pe logica pentru care este responsabil, fără a fi nevoie să facă ceva de genul fișierelor de import, să gestioneze diferitele structuri de directoare și să fie conștienți de mai mult decât ar trebui dezvoltatorul trebuie să retipări în mod constant totul doar pentru a putea accesa un fișier).
Și pentru cei cărora le place să se asigure că structura codului lor urmează structura organizatorică a fișierelor și directoarelor de pe disc, ne dă posibilitatea de a ne organiza proiectele exact așa.
Chiar și cu toate acestea, acest lucru este doar o modalitate și câteva avantaje ale spațiilor de nume și autoloading. Subiecte mai avansate sunt acoperite în manualul PHP și în alte proiecte open-source pe care vă recomandăm să le revizuiți dacă aveți timp.
În următorul tutorial, vom încheia această serie aplicând ceea ce am învățat în acest tutorial, introducând spații de nume și autoloading în pluginul nostru WordPress. Până atunci, dacă căutați alte materiale legate de WordPress, puteți găsi toate tutorialele mele anterioare pe pagina mea de profil și puteți să mă urmați pe blogul meu sau pe Twitter.
Nu ezitați să lăsați orice întrebări restante pe care le puteți avea despre spații de nume, autoloading sau WordPress în formularul de mai jos.
Resurse
 
Spații de nume
 
Clase automate
 
phpDocumentor
 



		
			
	   
	




Cod