Förra veckan höll jag min presentation på WordCamp Atlanta om namnutrymmen och automatisk laddning. (den fullständiga titeln var Namespaces, Autoloading, and Improving Plugin Architecture, men det är en munfull, eller hur?)

På grund av föredragets natur har jag valt att skriva ett inlägg som åtföljer inlägget, dela bilderna och dela ett exempel på plugin GitHub för att stödja föredraget.

Så om du var på plats, tack(!) och här kommer inlägget, jag lovade. Och för er som inte deltog hoppas jag att det här inlägget fortfarande hjälper till att demonstrera de koncept och ämnen jag diskuterade på WordCamp.

Namnutrymmen och automatisk laddning

Innan jag pratar om namnutrymmen och autoladdning i WordPress är anledningen till att jag vill prata om detta för att det direkt kan påverka kvaliteten på din kod och det kan göra det i månader och år framöver.

När allt kommer omkring är det inte många av oss utvecklare som redan ställer frågan:

Hur kan vi göra vår kod bättre än den redan är?

Och många av oss är smarta nog att veta det vi inte vet. Så vi står inför att arbeta inom de begränsningar vi får.

Ibland har vi tid att undersöka sätt att göra detta; andra gånger arbetar vi med den kunskap vi har. Och det är inget fel med det.

Men eftersom vi vet vad vi inte vet vet vi att det finns potential för mer.

Först, din kod

När det kommer till att prata om ämnen som namnutrymmen och autoloading i WordPress-sammanhang tror jag att vi ofta möts av blandade svar.

När allt kommer omkring kan vi prata om saker som Theme Customizer eller REST API eller något roligare.

Jag menar, "namespaces and autoloading" låter helt enkelt inte spännande eller framåtriktat när det jämförs med de nyare funktionerna och teknikerna som är tillgängliga, eller hur?

Men nej, de är inte riktigt tråkiga. Och genom det här inlägget och den medföljande presentationen och källkoden kommer jag att visa dig varför och hur de inte är det.

De är inte tråkiga

Jag tycker att det är rättvist att säga att utvecklare – åtminstone en del av oss eller en del av dem beroende på hur du ser dig själv – är ökända för att bråka om aspekter av programmering.

"Tråkigt samtal i alla fall."

Det är faktiskt inte alls ovanligt att höra någon bråka om det bästa sättet att initiera och skriva en for-loop som är så presterande som möjligt när man itererar över en liten uppsättning databas trots att vi har fyrkärniga processorer och 16 GB RAM i våra stationära maskiner.

Så om vi bryr oss så mycket om något så litet, så bryr vi oss om den större bilden. Saker som:

Förbättrad kod
Bättre organisation
Ökad underhållsbarhet
Enklare felsökning
Tjäna mer pengar (tja, kanske).

Och namnutrymmen och automatisk laddning kan leda direkt till allt ovan (ja, jag kan inte prata om pengar, men det har potential).

Om jag skulle sammanfatta rollnamnrymden och autoloadingplatsen i allt ovan, skulle jag säga att:

Namnutrymmen och autoloading leder till förbättrad kod genom bättre organisation, uppdelning eller modularisering och tätare relation genom deras koncept.

Detta ökar dessutom underhållbarheten eftersom koden är organiserad i paket vilket kan leda till enklare felsökning när produkten växer.

Allt detta kan leda till att spara tid eller en bättre användning av tid, vilket beroende på din affärsmodell kan påverka ditt resultat.

Men detta beskriver fortfarande inte någon av dessa saker. Men visst, vid det här laget låter de mer intressanta än när de först introducerades.

Så vad är de?

Innan vi går in på definitionerna av var och en och de roller de spelar, låt oss ta en titt på hur bristen på namnutrymmen och automatisk laddning i WordPress har påverkat din upplevelse negativt när du använder teman, plugins, tillägg eller vad du nu har.

Så låt oss backa ett ögonblick och titta på var och en av dem individuellt.

Namnutrymmen

Föreställ dig att du har ärvt ett projekt och att du ska börja arbeta med det. Säg att det är ett WordPress-plugin.

Du installerar det; du går för att aktivera den och sedan får du minst en av dessa:

Du kanske ser det där otäcka organiseringsmeddelandet högst upp i webbläsarfönstret som visar en stackspårning.
Kanske ser du ett meddelande som talar om någon konflikt med ett annat befintligt paket.
Eller kanske när du försöker aktivera ett plugin så uppdateras sidan men pluginet aktiveras inte.
Kanske har du till och med gjort en kodgranskning, och du ser klass_exists-kontroller i hela kodbasen.

Något eller allt av ovanstående kan naturligtvis bidra till problem med WordPress-projekt. Men namnutrymmen kan verkligen fixa mycket av detta för det mesta.

Det är sagt, anledningen till att du upplever dessa problem är att koden som du arbetar med är en del av det globala namnområdet (mot dess namnutrymme) och PHP gillar inte när det finns klasser och moduler som heter samma sak .

Men när du namnger något, ger du det dess område i förhållande till sig själv som fortfarande kommer att spela bra med andra komponenter även om de har samma klassnamn.

Autoloaders

När det gäller autoloaders är de lite mindre komplicerade på vissa sätt. Tänk först på koden du skriver eller koden som du arbetar med – särskilt inom ramen för WordPress-plugins – och tänk sedan på hur många gånger du skriver eller ser följande:

omfatta
inkludera_en gång
behöva
kräver_en gång

Och ibland ser du dem överst i filen som startar plugin-programmet, och ibland ser du dem utspridda i kodbasen.

Om de alla finns i en enda fil är det inte så illa eftersom du åtminstone vet var de är. Men om de är nedskräpade överallt, då har du ingen aning om var ett beroende förs in i systemet.

Autoloading kan lösa allt detta genom att ladda beroenden när det behövs (och för de som är intresserade är autoloading snabbare än manuell inkludering).

Namnutrymmen

Med allt detta sagt är vi redo att prata om både namnutrymmen och autoloading. Men namnutrymmen är det grundläggande konceptet, så vi börjar där.

Men efter allt ovanstående kan du se fördelarna med att använda dem. De kanske till och med är roliga, eller hur? Kanske?

Oavsett vilket behöver vi en definition som vi kan arbeta med när vi pratar igenom detta för resten av artikeln.

PHP-manualen ger följande definition :

Namnområden är designade för att lösa två problem som författare till bibliotek och applikationer stöter på när de skapar återanvändbara kodelement som klasser eller funktioner…

Och det är inte dåligt, men det är ganska långt, tekniskt, och det kan vara lite mycket för dem som precis har börjat. Så låt oss förenkla det lite för den här artikeln:

Lite bättre kanske?

Ett sätt att gruppera relaterade klasser och gränssnitt med liknande syfte.

Jag tänker inte prata om gränssnitt i det här föredraget; Men jag vet att det finns objektorienterade utvecklare på medelnivå som använder dem, så jag ville vara säker på att jag åtminstone nämner dem.

Ett praktiskt exempel

Jag gillar inte programmeringsexempel som inte ger verkliga eller praktiska tillämpningar. Ofta får vi exempel på saker som vi aldrig skulle kodifiera.

Hur många gånger har du läst en objektorienterad artikel och den ger ett exempel på en djurklass eller en bilklass? Vi kommer inte att programmera en bil.

Vi är mycket mer benägna att arbeta med filer. Så vi kommer att ta en titt på en uppsättning klasser som ansvarar för att läsa och skriva filer. Det vill säga, vi har varit bra objektorienterade programmerare och separerat våra klasser utifrån det ansvar de har.

Och ja, du kanske har gränssnitt; de faller dock utanför den här artikeln, så de kommer inte att inkluderas.

Så för vår FileReader kanske grunderna i klassen ser ut så här:

En klass för att läsa filer.

Observera att funktionen accepterar namnet på filen som den ska öppna för att läsa. Felkontrollen, hur den läser filen och vad den returnerar är allt upp till implementeringen av klassen.

Och för FileWriter har vi något sånt här:

En klass för att skriva filer.

Den här klassen, å andra sidan, accepterar informationen som den ska skriva till disken och namnet på filen som den ska skrivas till.

Återigen, som med exemplet ovan, inkluderar det inte felkontroll, skriva via en resurs, stänga resurserna och så vidare.

Men det här handlar inte om att arbeta med filer. Istället handlar det om att visa hur du namnger din kod, och dessa två exempel är tänkta att vara grundläggande för det.

Anteckningar om namnutrymmen

Det finns en varning till vad du ser i bilderna av exempelkoden ovan: Dessa klasser är inte namnavgränsade. Det vill säga, de bor i det globala namnutrymmet vilket gör dem mogna för konflikter med andra klasser.

Se på det så här: Föreställ dig att du paketerar den här koden i ett plugin för någon annan, och sedan laddar de ett annat plugin som också har som en FileReader eller en FileWriter. Eftersom det hela kommer att ingå i samma globala namnutrymme, kommer du att ställas inför en konflikt.

Kom ihåg:

Namnutrymmen är ett sätt att gruppera relaterade klasser och gränssnitt med liknande syfte.

Så låt oss ta klasserna och namnutrymmet koden.

Först kommer vi att tillhandahålla ett namnområde på toppnivå där dessa klasser och alla andra klasser kommer att ligga; sedan tillhandahåller vi ett underpaket (eller undernamnutrymme eller underutrymme som jag har hört dem kallade) i vilket dessa filklasser kommer att finnas.

Det betyder att vår FileReader nu kommer att se ut så här:

En namnavgränsad klass för att läsa filer.

Och vår FileWriter kommer nu att se ut så här:

En namnavgränsad klass för att skriva filer.

Först kan du se att det är enkelt att använda namnutrymmen: Du använder helt enkelt nyckelordet namnområde och deklarerar sedan namnområdet (som lika gärna kan vara WCATL) överst med underpaketen efter.

Men detta leder till andra ämnen – nämligen kring filorganisation, instansiering och autoloading – som alla är värda att ta upp.

På filorganisation

Vid det här laget är det viktigt att ha ett ord om filorganisation. Beroende på vem du pratar med kommer du att upptäcka att vissa utvecklare – överraskning, överraskning – har en åsikt om hur filer ska organiseras (och jag är inte annorlunda).

Å ena sidan behöver du inte organisera dina filer alls. Faktum är att du kan släppa varenda sak i rotkatalogen för ditt projekt, namnge informationen och vara redo att gå.

Oorganiserade filer

Ovanstående uppsättning filer är för ett litet projekt, så du kan föreställa dig hur många filer som skulle finnas för ett stort projekt.

Men när du har dina filer organiserade så här kan det göra det lite svårt att skriva en autoloader eftersom en autoloader behöver veta var den ska hitta filerna baserat på deras namnutrymme.

Det är här begreppen "logisk organisation" och "virtuell organisation" kommer in i bilden.

Logisk organisation hänvisar till hur filerna är organiserade på disken, som det du ser ovan. De är logiskt placerade i rotkatalogen.
Virtuell organisation hänvisar till hur filerna är organiserade med avseende på deras namnutrymmen. Det betyder att det finns kataloger och underkataloger som mappar till namnområdena, underpaketen och så vidare.

Så om du skulle ta ovanstående projekt, dess namnområden, dess underpaket och sedan organisera dem både logiskt och virtuellt, skulle det se ut ungefär så här:

Namnutrymmen och automatisk laddning: organiserade filer

Och även om du kan välja att organisera dina filer som du vill, är jag ett fan av att se till att det finns paritet mellan de två. Det vill säga, jag gillar att min logiska och min virtuella organisation matchar som du ser på bilden ovan.

När jag går över till att diskutera automatisk laddning, kommer du att se varför detta är viktigt.

Anteckningar om namnutrymmen

Vad händer dock när vi behöver instansiera klasser som är namnavgränsade? När klasser inte har namnintervall är det lätt att använda nyckelordet "nya".

Instantiering utan namnutrymme.

Men vi måste instansiera en namnavgränsad klass, vi måste ta det ett steg längre och använda det fullt kvalificerade namnet:

Namnutrymmen och autoladdning: Instantiering med ett namnområde.

Men det här blir krångligt, eller hur? Det här exemplet är inte så illa, men tänk om du jobbade på något med fler underpaket. Det skulle bli ganska krångligt, eller hur?

För det ändamålet kan vi använda det som kallas aliasing. Det är enkelt också. Vi kan definiera använd nyckelordet ‘använd’ högst upp i filen för att hänvisa till namnområdet vi vill alias och sedan använda det sista underpaketet som en del av aliaset för att instansiera vår klass.

Låter förvirrande, eller hur? Kanske hjälper det att se det i aktion:

Aliasing namnrymder.

Och det är allt som finns. Ja, du kan ta aliasing ett steg längre, men det här är så långt jag tar det i samband med den här artikeln.

Automatisk laddning

Vid det här laget har vi lagt grunden för autoloading. Ja, att arbeta genom namnutrymmen kan vara mycket jobb om du inte är van vid det; det är dock viktigt att förstå eftersom autoloading kräver lite arbete som kan vara oväntat om du aldrig har blivit introducerad till det tidigare.

Oavsett vilket är de viktigaste sakerna att komma ihåg när det gäller namnrymder vid det här laget:

Namnutrymmen är ett sätt att gruppera relaterade klasser och gränssnitt med liknande syfte.
Skapa paritet genom dina filer och namnutrymmen och se till att din logiska och virtuella organisation är densamma.

Och nu är det faktiskt dags att titta på autoloading.

Anmärkningar om automatisk laddning

Låt oss först titta på definitionen av automatisk laddning som tillhandahålls av PHP-manualen :

Funktionen spl_autoload_register() registrerar valfritt antal autoloaders, vilket gör att klasser och gränssnitt kan laddas automatiskt om de för närvarande inte är definierade. Genom att registrera autoloaders får PHP en sista chans att ladda klassen eller gränssnittet innan det misslyckas med ett fel.

Inte illa. Den är dock lång. Så precis som vi gjorde med namnutrymmen, låt oss använda en kortare definition för den här artikeln:

Ett sätt att automatiskt ladda gränssnitt och klasser utan att använda include and require-satser.

Återigen, vi kommer inte att använda gränssnitt i den här artikeln även om vissa utvecklare gör det. Och det kommer att ge arbetsdefinitionen för resten av denna artikel.

Ett praktiskt exempel

När du väl har ordnat dina filer, namnrymd och redo att laddas, då är det dags att göra just det, eller hur? Jag menar:

dina filer är organiserade,
du är redo att ladda dem

Så det är dags att göra det automatiskt, eller hur? Men det finns en hake. Hela "automatiskt ladda" filer kräver lite arbete.

Skriver en autoloader

Det vill säga, det är automatiskt, men det kräver ändå lite mer arbete från vår sida. Innan du går in i dessa steg är det viktigt att notera:

det är inte helt automatiserat,
vi måste skriva det.

Lika trevligt som det skulle vara att ha koden automatiskt laddad, måste vi läsa en del data, analysera den och sedan försöka ladda rätt fil.

Men förutsatt att du skriver det ordentligt och ditt namnområde och organiserar dina filer på samma sätt för varje projekt, kan du återanvända din autoloader. Det vill säga du skriver det en gång, och du kan använda det i andra projekt.

Steg för en autoloader

När du skriver en autoloader finns det bara några steg att följa. Autoloadern måste kunna svara på följande filer:

Var är filerna?
Hur heter de?
Finns filen?

Om allt ovanstående är sant (eller du kan svara "ja" på dem alla), så kommer autoloadern att göra vad den ska göra.

Vi ska ta en titt på lite kod om ett ögonblick, men det första att notera är att detta använder en funktion som heter spl_autoload_register.

SPL hänvisar till Standard PHP Library, och funktionen accepterar en funktion som ett argument, och den funktionen accepterar namnet på klassen som kommer att instansieras. Det är mer procedurmässigt än objektorienterat, och jag kommer att prata om detta ett ögonblick, men det är viktigt att ha i åtanke när du läser den här koden.

Här är den första delen av koden. Jag ska förklara vad den gör i efterhand:

Autoloading, del 1 – Hitta klassen

I den här delen av koden får funktionen det fullständiga namnet på klassen som ska instansieras (som "WCATLFileFileReader()").

Därefter delar den upp alla delar av det fullt kvalificerade namnet i delar. Namnet på klassen är det sista indexet i arrayen, och jag väljer att namnge mina filer som "class-filereader.php" så att funktionen skapar en variabel, $class_file, som refererar till namnet på filen.

Men vi är inte klara än. Vi måste fortfarande få det fullt kvalificerade namnet (det vill säga var filen finns på disken). Det här kan se ut ungefär så här:

Autoloading, del 2 – Att få det fullt kvalificerade namnet

Vid det här laget förbereder vi en variabel, $fullständigt_kvalificerad_sökväg, som kommer att referera till katalogen på översta nivån.

Därefter itererar koden genom alla index i arrayen och skapar en sökväg till klassfilen. Du kan föreställa dig detta som att bygga en sträng som "wcatlfile" som vi sedan kombinerar med $class_file.

Detta innebär att den fullt kvalificerade sökvägen till filen blir "wcatlfileclass-filereader.php."

Och slutligen inkluderar vi filen. Observera att den här koden inte kontrollerar om filen finns. Även om jag rekommenderar det, har det utelämnats för längdens skull och för att vi i vårt exempel vet att filen existerar.

Om filen inte finns finns det flera alternativ:

Kasta ett undantag,
Fånga ett undantag,
Visa ett eget felmeddelande,
Eller något annat alternativ som jag kanske överväger i den här artikeln.

Oavsett vilket är tanken att vara defensiv i din kod så att du kan förbereda dig på fallet att en fil inte existerar och du kan graciöst hantera felet.

På Autoloading

Innan du avslutar är det viktigt att notera följande:

Under hela exemplet har vi använt objektorienterad kod vid namnavstånd från koden. Det är trots allt ett objektorienterat koncept.
Vår autoloader är skriven i procedurkod. Vad ger?

I slutändan har detta att göra med standard PHP-biblioteket. Du kan skriva en objektorienterad autoloader, men jag tycker att det är lite överdrivet i många fall.

Processen att ladda en fil är en steg-för-steg-process så att skriva den på ett procedurmässigt sätt är en naturlig passform.

Slutligen kan andra välja att använda verktyg som Composer för att få in beroenden. Det här är fantastiska verktyg, och det finns många fördelar med att använda något sådant här; det är dock bortom begreppen och ämnena i den här artikeln och är bäst att lämna för ett framtida föredrag.

Resurser (och tack!)

Det här har varit en av de längsta artiklarna jag har skrivit för min webbplats.

Detta är delvis för att det är baserat på ett föredrag för en WordCamp och även för att jag vill se till att jag ger en solid introduktion och grund där du kan börja införliva namnrymder och autoladda i dina WordPress-plugins.

Utöver den här artikeln har jag även tillhandahållit följande resurser:

Bilderna i min presentation finns tillgängliga på SpeakerDeck.
Jag har koden från denna presentation tillgänglig för nedladdning på GitHub.

Och med det hoppas jag att detta ger en gedigen introduktion till namnfält och autoloading och att du kan börja införliva detta mer och mer i ditt arbete. Det gynnar ditt arbete och andra utvecklare som kan komma att använda ditt arbete också.

Inspelningskälla: tommcfarlin.com