Bruke navneområder og autolading i WordPress-plugin, del 3

I denne opplæringen skal vi ta en pause fra å skrive kode og se på hvilke PHP navneområder og autoloaders, hvordan de fungerer, og hvorfor de er fordelaktige. Da vil vi forberede oss til å pakke opp denne serien ved å implementere dem i kode.

Hvis du ikke er opptatt av alt vi har dekket i serien på dette punktet, anbefaler jeg at du går tilbake og vurderer hva vi har dekket så langt. I det minste vurderer du den forrige artikkelen da den skal legge grunnlaget for det vi snakker om i de neste to artiklene.

Nå som du er opptatt, er du klar over pluginet vi har jobbet med, hva det gjør, og hvordan det fungerer. Videre bør du ha et lokalt utviklingsmiljø satt opp som gjør at du kan jobbe med kildekoden. Hvis ikke, her er en rask oversikt over alt du trenger:

• Et lokalt utviklingsmiljø som inkluderer PHP 5.6.20, Apache-webserveren og en MySQL-databaseserver.
• En katalog ut av hvilken WordPress 4.6 er vert.
• En tekstredigerer eller IDE etter eget valg som du er komfortabel med å bruke til å skrive et plugin.
• Et arbeidskunnskap om WordPress Plugin API.

Forutsatt at du har alt det som er installert, satt opp og klar til å gå sammen med den nyeste versjonen av pluginet, så er vi klare til å gjenoppta diskusjonen om navnerom, autolading og WordPress-plugins.

På navnegrupper og autolading

For de som har jobbet i andre moderne programmeringsspråk, kan du være kjent med begrepet navneområder. Men selv om du har jobbet med PHP, er det ikke sannsynlig at du har sett dem mye, i hvert fall i sammenheng med WordPress.

For de av dere som har ikke hørt om dem eller hvem ha hørt om dem, men har ikke brukt dem, det er hva denne artikkelen handler om. Spesielt skal vi snakke om navneområder og autoloading, og i den neste opplæringen ser vi hvordan alt passer sammen.

Det vil si at vi skal ta det arbeidet vi har gjort med vårt plugin så langt, og deretter oppdatere det slik at det bruker navneområder og autoloading. Dette vil gi deg en praktisk forståelse av konseptene, samt noen få nye verktøy for å legge til utviklingsrepertoaret ditt når du jobber med ditt neste prosjekt.

Hva er navnegrupper?

Som med de fleste av mine opplæringsprogrammer, liker jeg å gi den formelle definisjonen og deretter bryte den ned i flere konversasjonsbetingelser. PHP-håndboken definerer navneområder som dette:

I den bredeste definisjonen er namespaces en måte å inkapslere elementer på. 

Det hjelper oss ikke nødvendigvis mye, gjør det? Man kan hevde at klasser gjør det samme som tillater attributter og funksjoner, kan begge generaliseres som elementer. Men håndboken fortsetter:

PHP Navnegrupper gir en måte å gruppere relaterte klasser, grensesnitt, funksjoner og konstanter.

Det er litt klarere, ikke sant? Dette betyr at når vi har en gruppe relaterte klasser, kan vi gruppere dem sammen i samme katalog eller lignende kataloger på filsystemet, men det er ingen måte å vite det ved å se på koden.

Navnegrupper gir oss muligheten til å gjøre det.

Tenk på det på denne måten: Tenk deg at du har et sett med funksjonalitet knyttet til å jobbe med CSVer. 

• Kanskje du har en klasse som er ansvarlig for å lese en CSV-fil, analysere innholdet og lese innholdet i en matrise. 
• Deretter har du en klasse som er ansvarlig for å ta det arrayet og skrive data til databasen basert på hva arrayet inneholder. 
• Etter det er det en klasse som er ansvarlig for å lese disse alternativene når et tredjepartsobjekt eller et annet område i koden må lese dataene som ble lest, analysert og lagret tidligere i prosjektets gjennomføring.

Alt denne funksjonaliteten skal omfatte flere klasser. Avhengig av hvordan objektorientert kode er løsningen din, kan du også ha et sett grensesnitt som klassene dine implementerer. Videre kan klassene bli organisert i en / csv katalog men brutt ned enda lenger inn i sine egne underkataloger. 

• /lese
• /skrive

Kanskje du ville velge å organisere strukturen litt annerledes, men for å holde diskusjonen så enkel som mulig, trodde jeg det ville være fornuftig. Så kanskje klassegrensesnittet (e) vil ligge i roten til / csv katalog, vil leseren være bosatt i /lese katalogen, og klassene som er ansvarlige for å skrive dataene til databasen, ville ligge i /skrive katalog.

Ingenting jeg har sagt så langt er uvanlig når det gjelder hvordan vi kan organisere våre filer. Men dette er hvor navneområder kommer inn i spill. 

Spesielt, hva om vi var i stand til å organisere våre klasser, så de også kartlagt til deres fysiske plassering i filsystemet?

Tenk på det på denne måten: La oss si at pluginet ditt heter Acme CSV, og klassene ovenfor er alle organisert i katalogene og underkatalogene og så videre. Hva kan navneområdene se ut for disse klassene, og hvordan ville de bli erklært i prosjektet?

Ta en titt på hva vi skal ringe til parser klasse. Denne klassen er lokalisert i / Csv / lese.

Og så la oss si at vi har vår klasse som skriver data til databasen:
Til slutt, la oss se hva navneområdet for klassen er som det leser data fra databasen:
Ingenting veldig komplisert, ikke sant? Selv om standarden ovenfor ikke er hvordan du ha å organisere filene dine, liker jeg å prøve å kartlegge klassene mine til deres plassering på disken. Det gjør det lettere å henvise til dem i fremtidig arbeid. 
På dette punktet er det egentlig ikke noe mer å se enn å forklare en type organisering av klassene dine på toppen av filene sine. Men når du begynner å innlemme autoloading, endres dette.
Et ord på pakker og underpakker
Før vi snakker om autoloading, skjønt, vil jeg ha en kort nedbrytning på @pakke og @subpackage koder som vi ofte er så vant til å se i filkommentarer.
For eksempel har du sannsynligvis sett noe lignende med hensyn til koden ovenfor:
Men når du henviser til phpDocumentor-dokumentasjonen, ser du følgende om @subpackage:
Denne taggen anses å være utdatert og kan fjernes i en fremtidig versjon av phpDocumentor. Det anbefales å bruke @package-taggenes evne til å gi flere nivåer.
Så @subpackage blir deprecated, noe som betyr at vi sannsynligvis ikke bør bry deg om å bruke det lenger. Hva med @pakke stikkord?
@Package-taggen brukes til å kategorisere strukturelle elementer i logiske underavdelinger.
Støtten for nesting på flere nivåer ligger nå bare i den taggen. Godt å vite, ikke sant? Dette betyr at koden vi ser over kan skrives noe slikt:
Visst, det er et enkelt eksempel, men det gjør sitt poeng. Jeg nevner dette fordi @subpackage er enda en tag som vi ofte ser i WordPress-basert PHP som vi trenger å unngå å bruke hvis vi ønsker å begynne å vedta nyere standarder.
Hva er autoloading?
Med det sagt, la oss komme tilbake til de viktigste emnene ved hånden. Siden vi har dekket navnegrupper, la oss se på autoloading. Ifølge PHP manualen:
Mange utviklere skriver objektorienterte applikasjoner opprett en PHP-kildefil per klasses definisjon. En av de største irritasjonene er å skrive en lang liste med nødvendige inkludert i begynnelsen av hvert skript (en for hver klasse).
Dette kunne ikke bli sagt noe bedre, kunne det? Likevel, det forklarer egentlig ikke hva autolading er. Det forklarer bare problemet det kan løse.
I PHP 5 er dette ikke lenger nødvendig ... [det støtter lasting] klasser og grensesnitt som skal lastes automatisk hvis de for øyeblikket ikke er definert.
Høres fantastisk ut, ikke sant? Men det er en advarsel, og vi skal utforske det i detalj i neste veiledning. Men til da er det her: For å få denne funksjonaliteten, må vi implementere en funksjon som vet hvor du skal lete etter filer som skal lastes og hvordan du analyserer katalogstrukturen til disse filene.
Det høres kjedelig ut, og det er noen tilfeller det kan være, men hvis du har en konsistent måte å organisere arbeidet på, kan autoladingskoden din være bærbar. Det vil si, du kan ta den funksjonen du skriver, slippe den inn i et PHP-basert prosjekt, og vær klar til å gå alt det samme.
Men denne spesifikke opplæringen handler ikke om å skrive kode. Det handler om å dekke ideen bak begrepet koden som vi skal implementere i neste opplæring.
Hvorfor er noe av dette Relevant?
Avhengig av hvem du spør, kan du se navnspaces og autoloading som nytt for PHP. For noen er dette sant. For andre har de jobbet med disse to konseptene en stund nå.
En av tingene om WordPress som kan holde den tilbake fra å vedta nyere funksjoner i PHP, er dens forpliktelse til bakoverkompatibilitet. Dette er ikke nødvendigvis en god ting eller en dårlig ting-det er et attributt for søknaden.
Men fordi WordPress har en minimumsversjon av PHP som den kjører på, er nyere språkfunksjoner ikke alltid vedtatt. Og når den minste versjonen er vedtatt, tar det WordPress-spesifikke utviklere en liten stund å begynne å bruke disse funksjonene i sin kode.
Og det er ikke en dårlig ting. Kort sagt, utviklerne holder tritt med søknaden i tempoet der den modnes.
Men som WordPress fortsetter å bevege seg fremover eller du har kontroll over miljøet der prosjektet kjører, kan du være interessert i å vedta noen av funksjonene i språket du ikke tidligere visste eksisterte, eller du visste ikke tidligere var tilgjengelig.
Navnegrupper og autolading er to kraftige egenskaper av språket som går langt i å gjøre koden mer lesbar, mer organisert og til og med litt mer vedlikeholdsbar. Så hvis du ennå ikke har brukt dem i noe av arbeidet ditt i WordPress, spesielt hvis du jobber med WordPress-plugins, ber jeg deg om å vurdere å gjøre det.
Konklusjon
Navnegrupper gir oss muligheten til å organisere vår kode på en måte som gjør den logiske gruppering av relaterte klasser mye lettere. Videre gir autoloading vår kode mer lesbarhet ved å redusere antall inkludere, include_once, krever, eller require_once uttalelser som vi trenger å bruke.
Dette gjør kildekoden vi skriver klarere, fordi den bare er fokusert på logikken som den er ansvarlig for, uten å måtte gjøre noe som å importere filer, håndtere ulike katalogstrukturer, og være klar over mer enn det burde (ikke si det utvikler må hele tiden skrive om alt bare slik at de kan få tilgang til en fil).
Og for de som liker å sørge for at strukturen i koden følger organisasjonsstrukturen til filene og katalogene på disken, gir den oss muligheten til å organisere våre prosjekter akkurat slik.
Selv med alt det som er sagt, er dette bare en måte og noen fordeler med navneområder og autolading. Flere avanserte emner er dekket i PHP-håndboken og i andre open-source-prosjekter som jeg anbefaler at du vurderer om du har tid.
I den neste opplæringen pakker vi opp denne serien ved å bruke det vi har lært i denne opplæringen, da vi presenterer navnerom og autoloading til vårt WordPress-plugin. Inntil da, hvis du leter etter annet WordPress-relatert materiale, kan du finne alle mine tidligere opplæringsprogrammer på min profilside, og du kan følge meg på bloggen min eller på Twitter.
Ikke nøl med å legge igjen noen utestående spørsmål du måtte ha om navneområder, autolading eller WordPress i skjemaet under.
ressurser
 
navnerom
 
Autoloading klasser
 
phpDocumentor
 



		
			
	   
	




Kode