Använda namnområden och autoloading i WordPress-plugins, del 3

I denna handledning kommer vi att ta en paus från att skriva kod och titta på vilka PHP namnområden och autoloaders som är, hur de fungerar och varför de är fördelaktiga. Då förbereder vi oss för att paketera upp denna serie genom att implementera dem i kod.

Om du inte är upptagen med allt vi har täckt i serien vid denna punkt rekommenderar jag att du går tillbaka och granskar vad vi hittills har täckt. Åtminstone granska den föregående artikeln eftersom den kommer att lägga grunden för vad vi ska prata om i de följande två artiklarna.

Nu när du är upptagen, är du medveten om det plugin vi har arbetat med, vad det gör och hur det fungerar. Vidare bör du ha en lokal utvecklingsmiljö som gör att du kan arbeta med källkoden. Om inte, här är en snabb sammanfattning av allt du behöver:

• En lokal utvecklingsmiljö som innehåller PHP 5.6.20, Apache webbservern och en MySQL databas server.
• En katalog där WordPress 4.6 är värd.
• En textredigerare eller IDE av ditt val som du är bekväm med att använda för att skriva ett plugin.
• En fungerande kunskap om WordPress Plugin API.

Om du antar att allt har installerats, konfigureras och redo att följa med den senaste versionen av plugin-programmet, är vi redo att fortsätta vår diskussion om namnområden, autoladdning och WordPress-plugins.

På namnområden och autoloading

För dem som har arbetat i andra moderna programmeringsspråk kan du vara bekant med begreppet namnområden. Men även om du har arbetat med PHP, är det inte troligt att du har sett dem mycket, åtminstone i samband med WordPress.

För er som har inte hört av dem eller vem ha hört av dem men har inte använt dem, det är vad den här artikeln handlar om. Specifikt kommer vi att prata om namnområden och autoloading och sedan i nästa handledning ser vi hur allt passar ihop.

Det vill säga vi ska ta det arbete vi har gjort med vårt plugin hittills och sedan uppdatera det så att det använder namnområden och autoloading. Detta ger dig en praktisk förståelse av koncepten samt några nya verktyg för att lägga till din utvecklingsrepertoar för när du arbetar med ditt nästa projekt.

Vad är namnområden?

Precis som med de flesta av mina tutorials, tycker jag om att ge den formella definitionen och sedan bryta ner den i mer konversation. PHP-handboken definierar namnområden så här:

I den bredaste definitionen är namespaces ett sätt att inkapslera objekt. 

Det hjälper oss inte nödvändigtvis mycket, gör det? Man kan hävda att klasser gör detsamma som tillåter attribut och funktioner kan båda generaliseras som föremål. Men manualen fortsätter:

PHP Namnrymder ger ett sätt att gruppera relaterade klasser, gränssnitt, funktioner och konstanter.

Det är lite tydligare, eller hur? Det innebär att när vi har en grupp relaterade klasser kan vi gruppera dem i samma katalog eller liknande kataloger på filsystemet, men det finns ingen möjlighet att veta det genom att titta på koden.

Namnrymder ger oss möjligheten att göra det.

Tänk på det på så vis: Tänk dig att du har en uppsättning funktionalitet som är relaterad till att arbeta med CSV. 

• Kanske har du en klass som ansvarar för att läsa en CSV-fil, analysera innehållet och läsa innehållet i en array. 
• Då har du en klass som ansvarar för att ta den matrisen och skriva data till databasen baserat på vad matrisen innehåller. 
• Därefter finns det en klass som ansvarar för att läsa dessa alternativ när en tredje parts objekt eller ett annat område i koden behöver läsa data som lästes, analyseras och sparas tidigare i projektets körning.

All denna funktionalitet bör omfatta flera klasser. Beroende på hur objektorienterad kod är din lösning, kan du också ha en uppsättning gränssnitt som dina klasser implementerar. Dessutom kan klasserna arrangeras i en / csv katalog men brutit ner ytterligare i sina egna underkataloger. 

• /läsa
• /skriva

Kanske skulle du välja att organisera strukturen lite annorlunda, men för att hålla diskussionen så enkel som möjligt trodde jag det skulle vara meningsfullt. Så kanske klassgränssnittet (erna) skulle ligga i roten till / csv katalog, skulle läsaren vara bosatt i /läsa katalog och de klasser som är ansvariga för att skriva data till databasen borde ligga i /skriva katalog.

Inget som jag har sagt hittills är vanligt när det gäller hur vi kan organisera våra filer. Men det är här namnrymden kommer in i spel. 

Närmare bestämt, om vi kunde organisera våra klasser så kartläggde de också till deras fysiska plats i filsystemet?

Tänk på det här: Låt oss säga att din plugin heter Acme CSV, och klasserna ovan är alla organiserade i deras kataloger och underkataloger och så vidare. Vad kan namnområdena se ut för dessa klasser, och hur skulle de bli deklarerade inom projektet?

Ta en titt på vad vi ska ringa till parser klass. Denna klass är belägen i / Csv / läs.

Och låt oss säga att vi har vår klass som skriver data till databasen:
Slutligen, låt oss se hur namnet på klassen är som det läser data från databasen:
Inget hemskt komplicerat, eller hur? Även om standarden ovan är inte hur du ha att organisera dina filer, tycker jag om att försöka kartlägga mina klasser till deras plats på disken. Det gör det lättare att hänvisa till dem i framtida arbete. 
Vid denna tidpunkt finns det verkligen inget mer att se bortom att förklara en typ av organisation av dina klasser högst upp i sina filer. Men när du börjar integrera autoloading ändras detta.
Ett ord på paket och subpackages
Innan vi pratar om autoloading, vill jag dock ha en kort nedbrytning på @paket och @subpackage taggar som vi ofta är vana vid att se i filkommentarer.
Du har till exempel sett något liknande här med avseende på vår kod ovan:
Men när du hänvisar till phpDocumentor dokumentationen ser du följande om @subpackage:
Den här taggen anses vara avskriven och kan tas bort i en framtida version av phpDocumentor. Det rekommenderas att använda @package-taggens förmåga att tillhandahålla flera nivåer.
Så @subpackage avlägsnas, vilket innebär att vi sannolikt inte skulle behöva använda det längre. Vad sägs om @paket märka?
Taggen @package används för att kategorisera strukturella element i logiska indelningar.
Stödet till flera nivåer ligger nu bara i den taggen. Bra att veta, eller hur? Det betyder att koden vi ser ovan kan skrivas något så här:
Visst, det är ett enkelt exempel, men det gör sin punkt. Jag nämner detta eftersom @subpackage är ännu en tagg som vi ofta ser i WordPress-baserad PHP som vi behöver för att undvika att använda om vi vill börja anta nya standarder.
Vad är autoloading?
Med det sagt, låt oss komma tillbaka till de primära ämnena till hands. Eftersom vi har täckt namnområden, låt oss titta på autoloading. Enligt PHP manualen:
Många utvecklare som skriver objektorienterade applikationer skapar en PHP-källfil per klassdefinition. En av de största irritationerna är att behöva skriva en lång lista över behövliga inkluderar i början av varje manus (en för varje klass).
Detta kunde inte sägas bättre, kan det? Ändå förklarar det inte riktigt vad autoloading är. Det förklarar bara det problem det kan lösa.
I PHP 5 är detta inte längre nödvändigt ... [det stöder laddning] klasser och gränssnitt som automatiskt laddas om de inte är definierade för närvarande.
Låter fantastiskt, eller hur? Men det finns en tillvägagångssätt, och vi kommer att undersöka det i detalj i nästa handledning. Men tills dess är det här: För att få denna funktionalitet måste vi implementera en funktion som vet var man ska leta efter filer att ladda och hur man analyserar katalogstrukturen hos dessa filer.
Det låter tråkigt, och i vissa fall kan det vara, men om du har ett enhetligt sätt att organisera ditt arbete kan din autoloading-kod vara bärbar. Det innebär att du kan ta den funktion du skriver, släpp den till ett PHP-baserat projekt och vara redo att gå på samma sätt.
Men denna specifika handledning handlar inte om att skriva kod. Det handlar om att täcka tanken bakom begreppen kod som vi ska genomföra i nästa handledning.
Varför är något av detta relevanta?
Beroende på vem du frågar kan du visa namespaces och autoloading som ny till PHP. För vissa är detta sant. För andra har de arbetat med dessa två begrepp ett tag nu.
En av sakerna om WordPress som kan hålla den tillbaka från att anta nyare funktioner i PHP är dess engagemang för bakåtkompatibilitet. Det här är inte nödvändigtvis en bra sak eller en dålig sak - det är ett attribut för ansökan.
Men eftersom WordPress har en minsta version av PHP som den körs på, används inte nya språkfunktioner alltid. Och när den minsta versionen är antagna, det tar lite tid för WordPress-specifika utvecklare att börja använda dessa funktioner i deras kod.
Och det är inte en dålig sak. Kortfattat följer utvecklarna takt med applikationen i takt med vilken den mognar.
Men som WordPress fortsätter att gå vidare eller du har kontroll över miljön där ditt projekt körs kan du vara intresserad av att anta några av funktionerna i det språk du inte tidigare visste existerat eller om du inte visste tidigare var tillgängliga.
Namnrymder och autoloading är två kraftfulla funktioner på språket som går långt för att göra koden mer läsbar, mer organiserad och till och med lite mer underhållbar. Så om du än har använt dem i något av ditt arbete i WordPress, speciellt om du arbetar med WordPress-plugins, uppmanar jag dig att överväga att göra det.
Slutsats
Namnrymder ger oss möjlighet att organisera vår kod på ett sätt som gör det logiskt att gruppera relaterade klasser mycket enklare. Dessutom ger autoloading vår kod mer läsbarhet genom att minska antalet inkludera, include_once, fordra, eller require_once uttalanden som vi behöver använda.
Detta gör källkoden som vi skriver tydligare genom att den endast är inriktad på den logik som den ansvarar för, utan att behöva göra något liknande importfiler, hantera olika katalogstrukturer och vara medveten om mer än vad den borde (än mindre utvecklaren måste ständigt skriva om allt bara så att de kan komma åt en fil).
Och för dem som gillar att se till att strukturen i deras kod följer organisationsstrukturen för filerna och katalogerna på disken, ger den oss möjligheten att organisera våra projekt exakt som.
Även med allt detta sagt är detta bara ett sätt och några fördelar med namnområden och autoloading. Mer avancerade ämnen omfattas av PHP-manualen och i andra open-source-projekt som jag rekommenderar att du granskar om du har tid.
I nästa handledning sätter vi in ​​den här serien genom att tillämpa det vi har lärt oss i den här handledningen när vi introducerar namespaces och autoloading till vårt WordPress-plugin. Fram till dess, om du letar efter andra WordPress-relaterade material kan du hitta alla mina tidigare handledning på min profilsida och du kan följa mig på min blogg eller på Twitter.
Tveka inte att lämna några utestående frågor du kan ha om namnområden, autoloading eller WordPress i formuläret nedan.
Medel
 
namnrymder
 
Autoloading klasser
 
phpDocumentor
 



		
			
	   
	




Koda