Varför bry sig om automatisk laddning i WordPress, del 1
En av de enklaste sakerna som vi kan göra när vi arbetar med WordPress-plugins är att släppa require_once eller include_once- satser i hela vår kod.
Och varför inte? Det är ett enkelt sätt att ta in alla nödvändiga filer eller beroenden för en viss klass, ha det lätt att läsa och inte behöva oroa sig för att skapa enorma filer med kod. Det vill säga, det hjälper oss att förenkla det vi skriver så att vi kan få våra klasser [oftast eller helst] att göra det de gör bra.
Men om du har läst den här sidan under det senaste året eller så, vet du att jag är ett fan av autoloading och det är något som jag tror att alla som arbetar med PHP – oavsett om du använder WordPress eller annan plattform – borde använda sig av.
Men det väcker två frågor, särskilt om du precis har börjat:
- Varför bry sig om autoloading när det finns andra sätt att hantera laddningsberoenden?
- Hur fungerar autoloading mot kompilerade språk?
Så jag tänkte att det skulle vara värt att svara på detta i de kommande inläggen.
Varför bry sig om autoloading?
Det korta är detta:
- require_once och include_once kan leda till kod som är svår att felsöka,
- det är svårt att spåra kod.
Men hur så?
1 Felsökning är svårt
När du skriver kod, om något är säkert, är det att det kommer att finnas något som inte fungerar som det är tänkt. Det ligger i naturen av vad vi gör, eller hur?
Så när det är dags att felsöka kod har vi alla våra strategier.
- några av oss väljer att använda echo eller var_dump för att spåra kod,
- använda ett plugin i WordPress,
- andra använder en debugger.
Även om det här inlägget inte handlar om hur man felsöker är det faktum att vi måste felsöka. Så om vi vet att vi kommer att behöva göra det, borde vi inte göra det så lätt för oss själva som möjligt?
PHP är ett dynamiskt skrivet språk, så det finns en hel del saker, i allmänhet, som tas om hand för oss när vi skriver koden. Det vill säga vissa saker antas eller tvingas fram när koden körs.
Anta till exempel att du arbetar med en sträng och att du jämför den med ett tal. Tolken kommer att göra vad den kan för att gissa vad det är du gör (tänker du analysera strängen till ett heltal eller vice versa?) och sedan arbeta med det.
Att enbart arbeta med variabler kan vara en övning i precision eftersom vi vill att vår kod ska läsas som vi har för avsikt. Varför överlåta det till tolken att gissa vad det är vi menar? Och om tolken måste göra extra arbete så gör människor det verkligen.
För det ändamålet, om vi vet att buggar kommer att introduceras och vi vet att det finns sätt att skriva renare kod, varför skulle vi inte göra det?
2 Spårning är svårt (eller kanske svårare?)
Men detta ger fortfarande ingen anledning till varför vi ska förlita oss på något som en autoloader kontra inbyggda funktioner i språket, eller hur?
Tänk på detta: Säg att du letar igenom en fil som försöker hitta en bugg och du stöter på en funktion som har någon kod, använder include_once och sedan använder någon annan kod.
Det betyder att du måste läsa koden, behålla den mentalt, hoppa in i en annan fil, förstå den koden och sedan återgå till den ursprungliga filen. Och detta förutsätter att den andra filen inte heller innehåller eller kräver andra filer.
Det kallas spagettikod av en anledning.
Med det sagt kan du se den problematik som detta introducerar när du väljer att kapsla den här koden under resten av ditt program. Kort sagt, du har nästlat inkluderingen av beroenden vilket i sig gör det svårare att spåra var något kan gå fel.
Detta är inte att säga att autoloading automatiskt fixar detta, men det är att säga att det inte behöver vara så här. Istället kan du skriva kod som instansierar klasser, anropar metoder och sedan exekverar kod utan att behöva inkludera något manuellt.
Mer läsbar, spårbar kod
När jag gör detta tycker jag att det tvingar oss att skriva renare kod, utan tvekan mer underhållbar kod. Det gör det också lättare att skriva kod som vi lättare kan spåra, och det är lättare att utnyttja med en debugger.
Det vill säga, vi kan ställa in brytpunkter på vissa ställen i vår kod, låta felsökaren automatiskt ta oss in i klassen som anropas och gå tillbaka ut i funktionen som anropade den.
Det betyder inte att det inte kan göras på något annat sätt, men fördelarna överväger vida alternativen. Och naturligtvis lämnar detta fortfarande frågan om varför autoloading (eller någon inkludering av tredjepartsfiler) överhuvudtaget behövs.
Men det är vad som kommer att tas upp i den andra delen av serien.
Annan läsning
Mitt inlägg om Namespaces och Autoloading i WordPress, samt Simple Autoloader för WordPress, är två andra resurser som jag uppenbarligen finner relaterade till just detta inlägg. Så om du har tid, kolla in dem (och tveka inte att öppna ett problem eller en pull-förfrågan på det enkla autoloader-projektet).