Accentsconagua

Objectgericht Autoloading in WordPress, deel 3

Code
Share

In de laatste zelfstudie hebben we de oorspronkelijke status van onze autoloader bekeken en vervolgens een proces van objectgeoriënteerde analyse en ontwerp doorlopen. Het doel hiervan is dat we alles wat we in deze serie en in de introductieserie hebben behandeld, met elkaar kunnen verbinden. 

Ten tweede is het doel om dit in zijn eigen tutorial te doen, zodat we de rest van deze tijd door onze klas kunnen lopen, zien hoe elk onderdeel in elkaar past, het in onze plug-in implementeren en dan zien hoe objectgeoriënteerd programmeren en het toepassen van principe van één verantwoordelijkheid kan leiden tot een meer gerichte, onderhoudbare oplossing.

Voordat we beginnen

Op dit punt neem ik aan dat je deze reeks hebt gevolgd. Zo niet, bekijk dan deel één en deel twee. Deze veronderstelt dat je tot nu toe hebt gevolgd.

Als je een beginner bent, raad ik aan de eerste serie ook in zijn geheel te lezen. Als je eenmaal bent ingehaald, zou je in een goede positie moeten zijn om de serie af te maken, aangezien we eindigen met de rest van de broncode die in deze tutorial wordt behandeld.

Wat we tot nu toe hebben gedaan

Voor een snel overzicht en om zeker te zijn dat we allemaal op dezelfde pagina staan, hebben we de volgende onderwerpen in deze serie behandeld:

  • de definitie van een klasseninterface bekeken
  • gezien hoe een klasse een interface implementeert
  • het beginsel van één enkele verantwoordelijkheid herzien
  • analyseerde onze bestaande autoloader
  • een routekaart gemaakt voor onze objectgerichte versie van de autoloader
  • en heeft een basisimplementatie ontworpen voor een objectgerichte versie van de autoloader

Op dit moment zijn we klaar om onze bestaande autoloader uit te wisselen met de objectgerichte code. Houd er echter rekening mee dat dit geen eenvoudige kwestie is van het wijzigen van bestanden. 

Wat we moeten doen

In plaats daarvan moeten we de bestanden maken, controleren of ze de WordPress-coderingsstandaarden volgen, implementeren, de implementatie testen om er zeker van te zijn dat de plug-in nog steeds werkt en vervolgens de bestaande autoloader verwijderen.

Het klinkt als een hoop werk, maar als onze analyse en het ontwerp van de vorige tutorial correct is uitgevoerd en blijkt te kloppen, dan zouden we weinig problemen moeten hebben met alles wat hierboven is vermeld.

Uw ontwikkelomgeving

Voordat we ingaan op de implementatie, wil ik een kort overzicht geven van de ontwikkelomgeving die je op je systeem zou moeten hebben. Technisch gezien is dit iets dat je al in vorige tutorials volgens de aanwijzingen zou moeten doen, maar ik wil zo volledig mogelijk zijn.

  • een lokale ontwikkelomgeving die geschikt is voor uw besturingssysteem
  • een map waaruit WordPress 4.6.1 wordt gehost
  • een teksteditor of IDE
  • kennis van de WordPress Plugin API

Met dat gezegd, laten we aan de slag gaan.

Object-georiënteerde implementatie

In dit gedeelte gaan we alle code opnieuw bekijken die we in de vorige zelfstudie hebben besproken; we gaan echter elk afzonderlijk bestand bekijken, samen met volledige documentatie.

Daarnaast gaan we het opnemen in ons project, zodat we aan het einde van de zelfstudie deze code kunnen gebruiken in plaats van de enkele, op procedures gebaseerde code die we eerder hebben gebruikt.

Merk op dat elk van de volgende bestanden een naam moet hebben als vermeld en moet worden opgenomen in de inc directory. Bovendien is dit alles beschikbaar om te downloaden met de blauwe knop in de zijbalk van dit bericht.

class-autoloader.php

namespace_validator = new NamespaceValidator (); $ this-> file_registry = new FileRegistry ();  / ** * Pogingen om de opgegeven bestandsnaam te laden. * * @param string $ bestandsnaam Het pad naar het bestand dat we proberen te laden. * / openbare laadfunctie ($ bestandsnaam) if ($ this-> namespace_validator-> is_valid ($ filename)) $ this-> file_registry-> load ($ filename);

class-namespace-validator.php

class-file-investigator.php
get_file_name ($ file_parts, $ current, $ i); if (count ($ file_parts) - 1! == $ i) $ filepath = trailingslashit ($ filepath);  retourneer $ filepath;  / ** * Haalt de locatie op van een deel van de bestandsnaam op schijf op basis van de huidige index van de * array die wordt onderzocht. * * @access private * @param array $ file_parts De array van alle delen van de bestandsnaam. * @param string $ current Het huidige deel van het te onderzoeken bestand. * @param int $ i De huidige index van de reeks $ file_parts om te bekijken. * @return string De naam van het bestand op schijf. * / private functie get_file_name ($ file_parts, $ current, $ i) $ filename = "; if (count ($ file_parts) - 1 === $ i) if ($ this-> is_interface ($ file_parts))  $ filename = $ this-> get_interface_name ($ file_parts); else $ filename = $ this-> get_class_name ($ current); else $ filename = $ this-> get_namespace_name ($ current); return $ bestandsnaam ; / ** * Bepaalt of het opgegeven bestand dat wordt onderzocht een interface is. * * @Access private * @param array $ file_parts De delen van het bestandspad die moeten worden bekeken. * @Return bool True als de interface zich in de bestandsnaam bevindt; anders , false. * / private function is_interface ($ file_parts) return strpos (strtolower ($ file_parts [count ($ file_parts) - 1]), 'interface'); / ** * Retrieves bestandsnaam van de interface op basis van de gespecificeerde delen van het bestand geslaagd * in de autoloader. * * @access private * @param array $ file_parts De array met delen van het bestand om te onderzoeken. * @return string De bestandsnaam van de interface. * / private fu nction get_interface_name ($ file_parts) $ interface_name = explode ('_', $ file_parts [count ($ file_parts) - 1]); $ interface_name = $ interface_name [0]; return "interface- $ interface_name.php";  / ** * Genereert de naam van de klassenbestandsnaam op schijf. * * @access private * @param string $ current Het huidige stuk van de bestandsnaam dat moet worden bekeken. * @return string De klassenbestandsnaam op schijf. * / private functie get_class_name ($ current) return "class- $ current.php";  / ** * Maakt een toewijzing van de naamruimte aan de mapstructuur. * * @access private * @param string $ current Het huidige deel van het bestand dat moet worden bekeken. * @return string Het pad van de naamruimte-toewijzing naar de directorystructuur. * / private functie get_namespace_name ($ current) return '/'. $ Stroom;  
class-file-registry.php
investigator = nieuwe FileInvestigator ();  / ** * Gebruikt de bestandsonderzoeker om de locatie van het bestand op schijf op te halen. Indien gevonden, dan * zal het het in het project opnemen; anders zal het een WordPress-foutbericht genereren. * * @param string $ filepath Het pad naar het bestand op schijf om op te nemen in de plug-in. * / public function load ($ filepath) $ filepath = $ this-> investigator-> get_filetype ($ filepath); $ filepath = rtrim (plugin_dir_path (dirname (__FILE__)), '/'). $ Filepath; if (file_exists ($ filepath)) include_once ($ filepath);  else wp_die (esc_html ('Het opgegeven bestand bestaat niet.'));  
De bestanden opnemen, de autoloader starten
Nu we onze bestanden hebben gemaakt, moeten we nog twee kleine wijzigingen aanbrengen:
     
  1. We moeten alle klassen in de inc-directory opnemen.
    2.  
  2. We moeten de oude autoloadercode verwijderen.
    3.  
  3. En we moeten onze nieuwe autoloader gebruiken met de spl_autoload_register functie.
    4.  
Uiteindelijk zou de definitieve versie van autoload.php er als volgt uit moeten zien:
En het zal precies datgene bereiken wat we hierboven hebben geschetst.
Maar wacht even, ik krijg een foutmelding!
Op dit moment heb je veel werk verzet. U hebt uw volledige autoloader opnieuw geformuleerd om objectgeoriënteerd programmeren te gebruiken. Je hebt je klassen en functies gedocumenteerd. U hebt nieuwe bestanden gemaakt, code uit oude bestanden verwijderd en u bent klaar om te controleren of alles naar behoren werkt.
Dus, zoals elke ontwikkelaar zou doen, start u het browservenster om de pagina te verversen, alleen om een ​​foutmelding te krijgen:
Gelukkig is dit een gemakkelijke oplossing. Het probleem is dat we onze metabox te vroeg proberen toe te voegen. Om dit op te lossen, werken we het in het methode in onze Meta_Box klasse om dit op te nemen:
En dan introduceren we een functie die zal worden gekoppeld aan het werk dat we net hebben gedaan:
display, 'render'), 'post', 'side', 'high'); 
Op dit punt moet u de nieuwe code zonder problemen, geen waarschuwingen, geen mededelingen en geen fouten kunnen uitvoeren.
Conclusie
Het doorwerken van dit alles leek misschien veel te zijn geweest - en dat was het ook! Maar het leuke is dat het in drie tutorials veel aandacht heeft gekregen, en het bouwde voort op het werk van een vorige serie. In dat opzicht zijn veel nieuwe onderwerpen behandeld en nieuwe technieken geleerd.
Merk op dat ik regelmatig schrijf voor Envato Tuts +, en je kunt al mijn eerdere tutorials vinden op mijn profielpagina. Bovendien bespreek ik vaak softwareontwikkeling in de context van WordPress op mijn blog en op Twitter, dus voel je vrij om mij op elke plaats te volgen.
Met dat gezegd, bestudeer de code die we in deze serie hebben behandeld (en misschien de voorafgaande) en kijk of je sommige van deze technieken niet kunt gebruiken in je bestaande of toekomstige werk.
Middelen
     
  •  Gebruik van naamruimten en automatisch laden in WordPress-plug-ins
    •  
  • Objectgericht Autoloading in WordPress, deel 1
    •  
  • Objectgericht Autoloading in WordPress, deel 2
    •  
  • namespaces
    •  
  • autoloading
    •  
  • interfaces
    •  
  • De WordPress Plugin-API
    •  
  • Single Responsibility Principle
    •  





	
	
			
	   
	







Code
×