Autoloading orientato agli oggetti in WordPress, parte 3

Nell'ultimo tutorial, abbiamo esaminato lo stato originale del nostro autoloader e quindi abbiamo esaminato un processo di analisi e progettazione orientata agli oggetti. Lo scopo di questo è che possiamo legare insieme tutto ciò che abbiamo trattato in questa serie e nella serie introduttiva. 

In secondo luogo, lo scopo di fare questo nel suo tutorial è così che possiamo passare il resto del tempo a camminare attraverso la nostra classe, vedere come ciascuna parte si adatta, implementarla nel nostro plugin e poi vedere come applicare la programmazione orientata agli oggetti e il principio della responsabilità unica può portare a una soluzione più mirata e sostenibile.

Prima di iniziare

A questo punto, presumo che tu abbia seguito questa serie. In caso contrario, si prega di rivedere la parte 1 e la seconda parte. Questo presuppone che tu abbia seguito fino ad ora.

Se sei un principiante, ti consiglio di leggere anche la serie iniziale nella sua interezza. Una volta raggiunto, dovresti essere in una buona posizione per completare la serie, mentre concludiamo con il resto del codice sorgente trattato in questo tutorial.

Ciò che abbiamo fatto fino ad ora

Per fornire un riepilogo rapido e per assicurarci che siamo tutti sulla stessa pagina, abbiamo trattato i seguenti argomenti in questa serie:

• rivisto la definizione di un'interfaccia di classe
• visto come una classe implementa un'interfaccia
• rivisto il principio della responsabilità unica
• analizzato il nostro autoloader esistente
• creato una tabella di marcia per la nostra versione orientata agli oggetti del caricatore automatico
• e progettato un'implementazione di base per una versione orientata agli oggetti del caricatore automatico

A questo punto, siamo pronti per sostituire il nostro autoloader esistente con il codice basato su oggetti. Si noti, tuttavia, che non si tratta semplicemente di modificare i file. 

Cosa dobbiamo fare

Invece, avremo bisogno di creare i file, assicurarsi che stiano seguendo gli standard di codifica di WordPress, implementarli, testarne l'implementazione per assicurarsi che il plugin funzioni ancora, e quindi rimuovere il caricatore automatico esistente.

Sembra un sacco di lavoro, ma se la nostra analisi e il design del precedente tutorial sono stati eseguiti correttamente e si dimostrano accurati, allora dovremmo avere un piccolo problema nel fare tutto quanto elencato sopra.

Il tuo ambiente di sviluppo

Prima di passare all'implementazione, voglio fornire una rapida panoramica dell'ambiente di sviluppo che dovresti avere sul tuo sistema. Tecnicamente, questo è qualcosa che dovresti già aver eseguito come da istruzioni precedenti, ma voglio essere il più completo possibile.

• un ambiente di sviluppo locale adatto al tuo sistema operativo
• una directory da cui è stato ospitato WordPress 4.6.1
• un editor di testo o IDE
• conoscenza dell'API del plugin WordPress

Detto ciò, iniziamo.

Implementazione orientata agli oggetti

In questa sezione, rivedremo tutto il codice che abbiamo esaminato nel precedente tutorial; tuttavia, esamineremo ogni singolo file insieme alla documentazione completa.

Inoltre, lo includeremo nel nostro progetto in modo che alla fine del tutorial, saremo in grado di utilizzare questo codice al posto del singolo codice procedurale che abbiamo usato in precedenza.

Si noti che ognuno dei seguenti file deve essere nominato come elencato e dovrebbe essere incluso nel file inc directory. Inoltre, tutto questo è disponibile per il download utilizzando il pulsante blu nella barra laterale di questo post.

class-autoloader.php

namespace_validator = new NamespaceValidator (); $ this-> file_registry = new FileRegistry ();  / ** * Tenta di caricare il nome file specificato. * * @param string $ nomefile Il percorso del file che stiamo tentando di caricare. * / carico funzione pubblica ($ nomefile) if ($ this-> namespace_validator-> is_valid ($ nomefile)) $ this-> file_registry-> load ($ nomefile);  

class-namespace-validator.php

class-file-investigator.php
get_file_name ($ file_parts, $ current, $ i); if (count ($ file_parts) - 1! == $ i) $ filepath = trailingslashit ($ filepath);  restituisce $ filepath;  / ** * Recupera la posizione di una parte del nome file sul disco in base all'indice corrente dell'array * in esame. * * @accesso privato * @param array $ file_parts La matrice di tutte le parti del nome del file. * @param string $ current La parte corrente del file da esaminare. * @param int $ i L'indice corrente dell'array di $ file_parts da esaminare. * @return string Il nome del file sul disco. * / private function 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 $ filename ; / ** * Determina se il file specificato in esame è un'interfaccia. * * @Accesso privato * @param array $ file_parts Le parti del percorso file da esaminare. * @Return bool Vero se l'interfaccia è contenuta nel nome file; altrimenti , false. * / private function is_interface ($ file_parts) return strpos (strtolower ($ file_parts [count ($ file_parts) - 1]), 'interface'); / ** * Recupera il nome file dell'interfaccia in base al parti specificate del file passato * nel caricatore automatico. * * @accesso privato * @param array $ file_parts L'array di parti del file da esaminare. * @return string Il nome file dell'interfaccia. * / 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";  / ** * Genera il nome del nome file della classe su disco. * * @accesso privato * @param stringa $ corrente Il pezzo corrente del nome del file da esaminare. * @return string Il nome file della classe sul disco. * / private function get_class_name ($ current) return "class- $ current.php";  / ** * Crea una mappatura dello spazio dei nomi nella struttura della directory. * * @accesso privato * @param stringa $ corrente La parte corrente del file da esaminare. * @return string Il percorso della mappatura dei nomi nella struttura della directory. * / private function get_namespace_name ($ current) return '/'. $ Corrente;  
class-file-registry.php
investigatore = nuovo FileInvestigator ();  / ** * Utilizza l'investigatore di file per recuperare la posizione del file sul disco. Se trovato, quindi * lo includerà nel progetto; in caso contrario, genererà un messaggio di errore WordPress. * * @param string $ filepath Il percorso del file sul disco da includere nel plug-in. * / carico di funzione pubblica ($ filepath) $ filepath = $ this-> investigator-> get_filetype ($ filepath); $ filepath = rtrim (plugin_dir_path (dirname (__FILE__)), '/'). $ Percorsofile; if (file_exists ($ filepath)) include_once ($ filepath);  else wp_die (esc_html ('Il file specificato non esiste.'));  
Compresi i file, avvio del caricatore automatico
Ora che abbiamo creato i nostri file, abbiamo bisogno di fare altre due piccole modifiche:
 
Dobbiamo includere tutte le classi nella directory inc.
 
Abbiamo bisogno di sbarazzarci del vecchio codice del caricatore automatico.
 
E abbiamo bisogno di usare il nostro nuovo autoloader con il spl_autoload_register funzione.
 
In definitiva, la versione finale di autoload.php dovrebbe apparire così:
E realizzerà esattamente ciò che abbiamo delineato sopra.
Ma aspetta, sto ottenendo un errore!
A questo punto, hai fatto un sacco di lavoro. Hai rifattorizzato l'intero caricatore automatico per utilizzare la programmazione orientata agli oggetti. Hai documentato le tue classi e funzioni. Hai creato nuovi file, rimosso il codice dai vecchi file e sei pronto per assicurarti che tutto funzioni come previsto.
Quindi, come farebbe qualsiasi sviluppatore, si avvia la finestra del browser per aggiornare la pagina, solo per mostrare un messaggio di errore:
Fortunatamente, questa è una soluzione semplice. Il problema è che stiamo tentando di aggiungere la nostra meta-box troppo presto. Per risolvere questo problema, aggiorneremo il dentro metodo nel nostro Meta_Box classe per includere questo:
E poi introdurremo una funzione che sarà agganciata al lavoro che abbiamo appena fatto:
display, 'render'), 'post', 'side', 'high'); 
A questo punto, dovresti essere in grado di eseguire il nuovo codice senza problemi, senza avvisi, senza notifiche e senza errori.
Conclusione
Lavorare attraverso tutto questo potrebbe sembrare molto, ed è stato! Ma la cosa bella è che ha coperto molto terreno in tre tutorial, e ha costruito sul lavoro di una serie precedente. A tale riguardo, sono stati trattati molti nuovi argomenti e sono state apprese nuove tecniche.
Nota che scrivo regolarmente per Envato Tuts +, e puoi trovare tutti i miei tutorial precedenti sulla mia pagina del profilo. Inoltre, discuto spesso di sviluppo di software nel contesto di WordPress sul mio blog e su Twitter, quindi sentitevi liberi di seguirmi in entrambi i posti.
Detto ciò, studia il codice che abbiamo trattato durante questa serie (e forse quella precedente) e vedi se non puoi impiegare alcune di queste tecniche nel tuo lavoro esistente o futuro.
risorse
 
 Utilizzo di spazi dei nomi e caricamento automatico nei plugin di WordPress
 
Autoloading orientato agli oggetti in WordPress, parte 1
 
Autoloading orientato agli oggetti in WordPress, parte 2
 
Namespace
 
Caricamento automatico
 
interfacce
 
L'API del plugin WordPress
 
Principio della singola responsabilità
 



		
			
	   
	




Codice