Disaccoppiamento della logica di dominio in WordPress

Ricorda che WordPress utilizza il modello di progettazione basato sugli eventi e sebbene spesso ci riferiamo ad azioni e filtri, il concetto si riduce agli hook. Il flusso di controllo attraverso il programma è più o meno questo:

1. Eseguire il programma,
2. Ogni volta che il programma si trova su un hook (in WordPress, vedremo do_actiono apply_filters), scorrere tutti gli hook registrati,
3. Riporta il controllo al programma,
4. Esegui fino alla fine.

Questo non è completamente diverso dal modello Publisher/Subscriber (o PubSub, in breve) ma c’è una differenza fondamentale: il modello Event-Driven segnala semplicemente che è successo qualcosa e se ci sono hook, si attiveranno. Il modello PubSub dirà a un abbonato registrato di fare qualcosa.

Ad ogni modo, torniamo agli hook in WordPress. Mantenere i due concetti di hook che abbiamo può essere fatto più facilmente pensandoli in questo modo:

• Le azioni servono a fare qualcosa,
• I filtri servono per l’elaborazione dei dati.

Se stai cercando di avvicinarti allo sviluppo di WordPress in modo orientato agli oggetti, accoppiare strettamente il tuo codice al core di WordPress registrando le tue classi tramite hook all’applicazione principale non è una buona idea.

In altre parole, non registrare la tua logica aziendale con WordPress. Tienili separati. Ecco una cartina di tornasole per verificare se il tuo lavoro è strettamente accoppiato con WordPress: se non puoi eseguire uno unit test contro la tua classe senza caricare WordPress, è strettamente accoppiato.

Allora qual è la soluzione? Delegazione.

Logica di dominio in WordPress

La logica di dominio e la logica di business sono intercambiabili per quanto mi riguarda, quindi se hai letto i post precedenti su questo e ne ho parlato in diversi modi, sai perché.

Credito

Successivamente, l’idea di delegare la logica da WordPress a una classe per la logica di dominio in WordPress viene eseguita da una classe intermedia che è responsabile di quanto segue:

1. Sottoscrivendo un hook,
2. Delegare il lavoro a una classe.

So che le lezioni dovrebbero fare "una cosa bene", ma cosa succederebbe se quella cosa fosse la delega?

impegnarsi (poteri, funzioni, ecc.) a un altro come agente

il dizionario

E per affidare correttamente la funzionalità a un altro agente o, nel nostro caso, a una classe, devi avere la capacità di sapere cosa stai delegando. A volte, per fare una cosa è necessario conoscere diverse informazioni.

Quindi, che aspetto ha in pratica parlando? Immagina di avere un [AbstractSubscriber](https://github.com/tommcfarlin/remove-empty-shortcodes/blob/master/src/Subscriber/AbstractSubscriber.php)a prenderà il nome di un hook nel suo costruttore:

E poi, una volta terminato, la loadfunzione invierà il lavoro a una classe responsabile dell’effettiva esecuzione dell’elaborazione.

Prendi, ad esempio, questo codice da Remove Empty Shortcodes :

Una classe si iscrive a un evento particolare, ad esempio [the_content](https://developer.wordpress.org/reference/functions/the_content/), e quindi delega il lavoro alla classe di elaborazione del contenuto successivo.

Ciò consente letteralmente al file di bootstrap del plug-in di creare un’istanza del delegato. Il delegato si collega quindi a WordPress e quando WordPress arriva al punto di esecuzione corretto, il delegato invia la responsabilità alla classe responsabile dell’elaborazione.

L’intera architettura non solo è completamente riutilizzabile (vedi l’uso di una classe astratta sopra), ma ci consente di disaccoppiare la logica di dominio da WordPress e testarla in isolamento.

Altro sulla separazione delle preoccupazioni

Ho scritto altri post sulla separazione delle preoccupazioni:

• Separazione delle preoccupazioni con i modelli WordPress
• Separazione delle preoccupazioni con query e funzioni di supporto
• Programmazione WordPress: separare le preoccupazioni