Namespaces gebruiken en Autoloading in WordPress-plug-ins, deel 3

In deze zelfstudie nemen we een pauze om code te schrijven en te kijken naar PHP-naamruimten en autoloaders, hoe ze werken en waarom ze nuttig zijn. Vervolgens bereiden we ons voor om deze serie af te ronden door ze in code te implementeren.

Als je niet bent ingehaald door alles wat we in de serie op dit punt hebben behandeld, raad ik aan om terug te gaan en te bekijken wat we tot nu toe hebben behandeld. Bekijk op zijn minst het vorige artikel, want het zal de basis leggen voor waar we het over zullen hebben in de volgende twee artikelen.

Nu u bent ingehaald, bent u op de hoogte van de plug-in waaraan we hebben gewerkt, wat deze doet en hoe deze werkt. Verder moet u een lokale ontwikkelingsomgeving hebben ingesteld waarmee u met de broncode kunt werken. Zo niet, dan volgt hier een kort overzicht van alles wat u nodig hebt:

• Een lokale ontwikkelingsomgeving met PHP 5.6.20, de Apache-webserver en een MySQL-databaseserver.
• Een map waaruit WordPress 4.6 wordt gehost.
• Een teksteditor of IDE naar keuze die u prettig vindt om een ​​plug-in te schrijven.
• Een praktische kennis van de WordPress Plugin API.

Ervan uitgaande dat u dat allemaal hebt geïnstalleerd, ingesteld en klaar om mee te gaan met de nieuwste versie van de plug-in, zijn we klaar om onze discussie over naamruimten, autoloading en WordPress-plug-ins te hervatten..

Over Namespaces en Autoloading

Voor degenen die in andere moderne programmeertalen hebben gewerkt, bent u misschien bekend met het concept van naamruimten. Maar zelfs als je met PHP hebt gewerkt, is het niet waarschijnlijk dat je ze veel hebt gezien, in ieder geval in de context van WordPress.

Voor degenen onder u die hebben niet gehoord van hen of wie hebben gehoord van hen maar ze niet hebben gebruikt, dat is waar dit specifieke artikel over gaat. In het bijzonder gaan we het hebben over naamruimten en autoloading en dan zullen we in de volgende tutorial zien hoe alles bij elkaar past.

Dat wil zeggen dat we het werk dat we tot nu toe met onze plug-in hebben gedaan, zullen aannemen en het dan zullen bijwerken zodat het naamruimten en automatisch laden gebruikt. Dit geeft je een praktisch begrip van de concepten en een paar nieuwe hulpmiddelen om toe te voegen aan je ontwikkelingsrepertoire voor wanneer je aan je volgende project werkt.

Wat zijn naamruimten?

Zoals met de meeste van mijn tutorials, geef ik graag de formele definitie op en deel het vervolgens in meer gemoedelijke termen. De PHP-handleiding definieert naamruimten als deze:

In de breedste definitie zijn naamruimten een manier om items samen te vatten. 

Dat hoeft ons niet echt veel te helpen, toch? Je zou kunnen stellen dat klassen hetzelfde doen waardoor attributen en functies kunnen worden gegeneraliseerd als items. Maar de handleiding gaat door:

PHP-naamruimten bieden een manier om gerelateerde klassen, interfaces, functies en constanten te groeperen.

Dat is een beetje duidelijker, toch? Dit betekent dat wanneer we een groep verwante klassen hebben, we ze misschien samen in dezelfde map of vergelijkbare mappen op het bestandssysteem kunnen groeperen, maar er is geen manier om dat te weten door naar de code te kijken.

Namespaces geven ons de mogelijkheid om dat te doen.

Zie het op deze manier: stel je voor dat je een aantal functies hebt gerelateerd aan het werken met CSV's. 

• Misschien hebt u een klasse die verantwoordelijk is voor het lezen van een CSV-bestand, het parseren van de inhoud en het lezen van de inhoud in een array. 
• Dan hebt u een klasse die verantwoordelijk is voor het maken van die array en het schrijven van gegevens naar de database op basis van wat de array bevat. 
• Daarna is er een klasse die verantwoordelijk is voor het lezen van deze opties wanneer een object van derden of een ander gebied in de code de gegevens moet lezen die eerder in de uitvoering van het project zijn gelezen, geparseerd en opgeslagen..

Al deze functionaliteit zou meerdere klassen moeten omvatten. Afhankelijk van hoe object-georiënteerde code uw oplossing is, hebt u mogelijk ook een aantal interfaces die door uw klassen worden geïmplementeerd. Bovendien kunnen de lessen worden georganiseerd in een / csv map, maar nog verder onderverdeeld in hun eigen submappen. 

• /lezen
• /schrijven

Misschien zou je ervoor kiezen om de structuur een beetje anders te organiseren, maar om de discussie zo eenvoudig mogelijk te houden, dacht ik dat dit logisch zou zijn. Dus misschien zouden de klasseninterface (s) in de root van de / csv map, de lezer zou zich in de /lezen directory, en de klassen die verantwoordelijk zijn voor het schrijven van de gegevens naar de database zouden zich in de /schrijven directory.

Niets wat ik tot nu toe heb gezegd is buitengewoon in termen van hoe we onze bestanden kunnen ordenen. Maar dit is waar namespaces om de hoek komen kijken. 

Concreet, wat als we in staat waren om onze klassen te organiseren, zodat ze ook werden toegewezen aan hun fysieke locatie in het bestandssysteem?

Zie het op deze manier: laten we zeggen dat uw plug-in Acme CSV wordt genoemd, en de bovenstaande klassen zijn allemaal georganiseerd in hun mappen en submappen, enzovoort. Hoe zien de naamruimten er voor deze klassen uit en hoe zouden ze binnen het project worden verklaard?

Kijk eens naar wat we het zullen noemen parser klasse. Deze klasse bevindt zich in / Csv / gelezen.

En laten we zeggen dat we onze klasse hebben die gegevens naar de database schrijft:
Laten we tot slot zien hoe de naamruimte voor de klasse is die gegevens uit de database leest:
Niks vreselijk gecompliceerd, toch? Hoewel de bovenstaande standaard niet is hoe jij hebben om uw bestanden te ordenen, probeer ik mijn klassen graag op hun locatie op schijf te plaatsen. Het maakt het eenvoudiger om ernaar te verwijzen in toekomstige werkzaamheden. 
Op dit moment is er echt niet veel meer te zien dan een soort organisatie van je klassen boven aan hun bestanden te verklaren. Maar wanneer u begint autoloading te integreren, verandert dit.
Een woord over pakketten en subpakketten
Voordat we het echter over autoloading hebben, wil ik eerst een korte uitleg over de @pakket en @subpackage tags die we vaak gewend zijn aan het zien in bestandsopmerkingen.
U hebt bijvoorbeeld waarschijnlijk zoiets gezien als het gaat om onze code hierboven:
Maar als u naar de phpDocumentor-documentatie verwijst, ziet u het volgende over @subpackage:
Deze tag wordt beschouwd als verouderd en kan worden verwijderd in een toekomstige versie van phpDocumentor. Het wordt aanbevolen om de mogelijkheid van de @package tag te gebruiken om meerdere niveaus te bieden.
Zo @subpackage wordt verouderd, wat betekent dat we waarschijnlijk niet meer zouden moeten proberen het te gebruiken. Hoe zit het met de @pakket label?
De tag @package wordt gebruikt om structuurelementen in logische onderverdelingen in te delen.
De ondersteuning voor nesten op meerdere niveaus bevindt zich nu alleen in die tag. Goed om te weten, toch? Dit betekent dat de code die we hierboven zien, ongeveer als volgt kan worden geschreven:
Natuurlijk, het is een eenvoudig voorbeeld, maar het maakt zijn punt. Ik vermeld dit omdat @subpackage is nog een tag die we vaak zien in WordPress-gebaseerde PHP die we moeten vermijden om te gebruiken als we nieuwe normen willen gaan gebruiken.
Wat is Autoloading?
Met dat gezegd, laten we teruggaan naar de belangrijkste onderwerpen bij de hand. Omdat we namespaces hebben behandeld, laten we kijken naar autoloading. Volgens de PHP-handleiding:
Veel ontwikkelaars die objectgeoriënteerde applicaties schrijven, maken één PHP-bronbestand per klassendefinitie. Een van de grootste ergernissen is dat je aan het begin van elk script een lange lijst met nodig hebt (een voor elke klas).
Dit kon niet beter worden gezegd, toch? Toch legt het niet echt uit wat autoloading is. Het verklaart alleen het probleem dat het kan oplossen.
In PHP 5 is dit niet langer nodig ... [het ondersteunt laden] klassen en interfaces worden automatisch geladen als ze op dit moment niet zijn gedefinieerd.
Klinkt fantastisch, toch? Maar er is een voorbehoud, en we gaan het in de volgende tutorial in detail bekijken. Maar tot die tijd is het hier: om deze functionaliteit te verkrijgen, moeten we een functie implementeren die weet waar te zoeken naar te laden bestanden en hoe de directorystructuur van die bestanden te ontleden.
Het klinkt vervelend, en in sommige gevallen kan het zijn, maar als je een consistente manier hebt om je werk te organiseren, kan je autoloadingscode draagbaar zijn. Dat wil zeggen, je kunt de functie die je schrijft nemen, deze in elk PHP-gebaseerd project laten vallen, en klaar zijn om hetzelfde te doen.
Maar deze specifieke tutorial gaat niet over het schrijven van code. Het gaat over het bedekken van het idee achter de concepten van de code die we in de volgende tutorial zullen implementeren.
Waarom is een van deze relevant?
Afhankelijk van wie je het vraagt, kun je namespaces en autoloading zien als nieuw voor PHP. Voor sommigen is dit waar. Voor anderen werken ze al een tijdje met deze twee concepten.
Een van de dingen over WordPress die het kan weerhouden van het gebruik van nieuwere functies van PHP is de toewijding aan achterwaartse compatibiliteit. Dit is niet noodzakelijk een goede zaak of een slechte zaak, het is een attribuut van de applicatie.
Maar omdat WordPress een minimale versie van PHP heeft waarop het draait, worden nieuwere taalfuncties niet altijd overgenomen. En wanneer die minimumversie is aangenomen, duurt het een tijdje voor WordPress-specifieke ontwikkelaars om deze functies in hun code te gaan gebruiken.
En dat is geen slechte zaak. Kortom, de ontwikkelaars houden gelijke tred met de applicatie in het tempo waarin ze volwassen worden.
Maar naarmate WordPress verder gaat of als u controle heeft over de omgeving waarin uw project wordt uitgevoerd, is het misschien interessant om enkele van de functies van de taal te gebruiken waarvan u niet wist dat ze bestonden of waarvan u niet eerder wist dat deze beschikbaar waren.
Namespaces en autoloading zijn twee krachtige functies van de taal die een lange weg gaan om de code leesbaarder, georganiseerder en zelfs wat meer onderhoudbaar te maken. Dus als je ze nog moet gebruiken in je werk in WordPress, vooral als je met WordPress-plug-ins werkt, dan verzoek ik je dringend om dit te overwegen.
Conclusie
Namespaces geven ons de mogelijkheid om onze code zo te organiseren dat de logische groepering van gerelateerde klassen veel eenvoudiger wordt. Bovendien geeft autoloading onze code meer leesbaarheid door het aantal te verminderen omvatten, include_once, vereisen, of eenmalig benodigd verklaringen die we moeten gebruiken.
Dit maakt de broncode die we schrijven duidelijker in die zin dat deze alleen is gericht op de logica waarvoor hij verantwoordelijk is, zonder iets te hoeven doen als importbestanden, verschillende directorystructuren moet afhandelen en meer moet weten dan zou moeten (laat staan ​​de ontwikkelaar moet voortdurend alles opnieuw typen, zodat ze een bestand kunnen openen).
En voor degenen die ervoor willen zorgen dat de structuur van hun code de organisatiestructuur van de bestanden en directory's op de schijf volgt, kunnen we onze projecten precies zo organiseren.
Zelfs met dat alles gezegd, dit is slechts een manier en een paar voordelen van namespaces en autoloading. Meer geavanceerde onderwerpen komen aan de orde in de PHP-handleiding en in andere open-sourceprojecten die ik aanraad om deze te bekijken als je tijd hebt.
In de volgende tutorial sluiten we deze serie af met wat we hebben geleerd in deze tutorial, omdat we namespaces introduceren en autoloading toepassen op onze WordPress-plug-in. Tot die tijd, als je op zoek bent naar ander WordPress-gerelateerd materiaal, kun je al mijn vorige tutorials op mijn profielpagina vinden en kun je me volgen op mijn blog of op Twitter.
Aarzel niet om openstaande vragen over namespaces, autoloading of WordPress in het onderstaande formulier achter te laten.
Middelen
 
namespaces
 
Lessen autoload
 
phpDocumentor
 



		
			
	   
	




Code