Perché preoccuparsi del caricamento automatico in WordPress, parte 1
Una delle cose più semplici che possiamo fare quando lavoriamo sui plugin di WordPress è eliminare le istruzioni require_once o include_once nel nostro codice.
E perchè no? È un modo semplice per importare tutti i file o le dipendenze necessari per una determinata classe, renderlo facilmente leggibile e non doversi preoccupare di creare enormi file di codice. Cioè, ci aiuta a semplificare ciò che stiamo scrivendo in modo che siamo in grado di fare in modo che le nostre classi [principalmente o idealmente] facciano bene ciò che stanno facendo.
Se hai letto questo sito nell’ultimo anno o giù di lì, però, sai che sono un fan del caricamento automatico ed è qualcosa che penso che chiunque lavori con PHP, indipendentemente dal fatto che tu stia utilizzando WordPress o un’altra piattaforma, dovrebbe uso.
Ma solleva due domande soprattutto se sei appena agli inizi:
- Perché preoccuparsi del caricamento automatico quando ci sono altri modi per gestire le dipendenze di caricamento?
- In che modo il caricamento automatico si confronta con i linguaggi compilati?
Quindi ho pensato che sarebbe valsa la pena rispondere a questo nei prossimi due post.
Perché preoccuparsi del caricamento automatico?
Il corto è questo:
- require_once e include_once possono portare a codice difficile da eseguire il debug,
- è difficile rintracciare il codice.
Ma come mai?
1 Il debug è difficile
Quando si scrive codice, se qualcosa è certo, è che ci sarà qualcosa che non funzionerà come previsto. È nella natura di ciò che facciamo, giusto?
Quindi, quando arriva il momento di eseguire il debug del codice, tutti abbiamo le nostre strategie.
- alcuni di noi scelgono di usare echo o var_dump per tracciare il codice,
- usa un plugin in WordPress,
- altri usano un debugger.
Sebbene questo post non riguardi come eseguire il debug, è il fatto che dobbiamo eseguire il debug. Quindi, se sappiamo che dovremo farlo, non dovremmo renderlo il più facile possibile con noi stessi?
PHP è un linguaggio tipizzato dinamicamente, quindi ci sono molte cose, in generale, di cui ci occupiamo ogni volta che scriviamo il codice. Cioè, alcune cose vengono dedotte o forzate ogni volta che viene eseguito il codice.
Ad esempio, supponi di lavorare con una stringa e di confrontarla con un numero. L’interprete farà il possibile per indovinare cosa stai facendo (stai cercando di analizzare la stringa in un numero intero o viceversa?) e quindi lavorare con quello.
Lavorare solo con le variabili può essere un esercizio di precisione perché vogliamo che il nostro codice venga letto come intendiamo. Perché lasciare all’interprete il compito di indovinare cosa intendiamo? E se l’interprete deve fare un lavoro extra, gli umani lo fanno sicuramente.
A tal fine, se sappiamo che verranno introdotti bug e sappiamo che ci sono modi per scrivere codice più pulito, perché non dovremmo farlo?
2 Il tracciamento è difficile (o forse più difficile?)
Ma questo ancora non fornisce una ragione per cui dovremmo fare affidamento su qualcosa come un caricatore automatico rispetto a strutture integrate del linguaggio, vero?
Considera questo: supponiamo che stai guardando un file cercando di trovare un bug e ti imbatti in una funzione che ha del codice, usa include_once, quindi usa un altro codice.
Ciò significa che devi leggere il codice, tenerlo archiviato mentalmente, saltare in un altro file, comprendere quel codice, quindi tornare al file originale. E questo presuppone che anche il secondo file non includa o richieda altri file.
Si chiama codice spaghetti per un motivo.
Detto questo, puoi vedere la difficile situazione che questo introduce quando scegli di annidare questo codice nel resto del tuo programma. In breve, hai annidato l’inclusione delle dipendenze che intrinsecamente rende più difficile tracciare dove qualcosa potrebbe andare storto.
Questo non vuol dire che il caricamento automatico risolva automaticamente questo problema, ma significa che non deve essere così. Invece, puoi scrivere codice che istanzia classi, chiama metodi e quindi esegue codice senza la necessità di includere nulla manualmente.
Codice più leggibile e tracciabile
In questo modo, trovo che ci costringa a scrivere codice più pulito, probabilmente più gestibile. Inoltre, semplifica la scrittura di codice che possiamo tracciare più facilmente e che è più facile sfruttare con un debugger.
Cioè, possiamo impostare punti di interruzione in determinati punti del nostro codice, fare in modo che il debugger ci porti automaticamente nella classe che viene invocata e tornare indietro nella funzione che lo stava chiamando.
Questo non significa che non possa essere fatto in nessun altro modo, ma i vantaggi superano di gran lunga le alternative. E, naturalmente, questo lascia ancora la questione del perché sia necessario il caricamento automatico (o qualsiasi inclusione di file di terze parti).
Ma questo è ciò che verrà trattato nella seconda parte della serie.
Altra lettura
Il mio post su Namespaces e Autoloading in WordPress, così come il Simple Autoloader per WordPress, sono altre due risorse che trovo ovviamente correlate a questo particolare post. Quindi, se hai tempo, dai un’occhiata (e non esitare ad aprire un problema o una richiesta pull sul semplice progetto di caricamento automatico).