Programmazione WordPress: separare le preoccupazioni

Quando si tratta di creare classi per i plugin di WordPress, mi è stato chiesto perché mi preoccupo di separare le funzionalità in iscritti e in altre classi.

Penso che questa sia una buona domanda perché aiuta a capire due cose:

1. il ruolo di un abbonato in relazione all’architettura di WordPress,
2. il ruolo delle altre classi in relazione a ciò che stai costruendo (e come questo può aiutare con altre cose come unit test e così via).

Quindi ho pensato perché non rispondere sotto forma di un breve post? Documenterà il perché dietro il cosa [e mi darà un posto dove aggiornarmi se le cose cambieranno in futuro].

Programmazione WordPress: abbonati e oggetti di dominio

Considero le classi che non sono oggetti di dominio di abbonati che provengono dall’approccio di sviluppo software della progettazione basata sul dominio.

Questo è al di fuori dello scopo di questo post, ma vale la pena menzionarlo se non altro perché fornisce un contesto a ciò che altrimenti sarebbe considerato gergo.

1 Abbonati

Ma prima, gli abbonati.

Poiché WordPress si basa su un sistema di hook, un sistema basato sul modello di progettazione basato sugli eventi, è utile disporre di una classe che risponda ogni volta che viene generato un evento.

Questo può essere per qualsiasi hook WordPress predefinito o qualsiasi hook personalizzato. Non importa.

E non voglio rendere la lezione più complicata del necessario, quindi tendo a pensarle in questo modo:

Un abbonato risponde ogni volta che si verifica un evento specifico.

E questo è tutto. Questo evento può essere qualcosa come after_theme_setup o the_content o anche init. Non importa.

Aspetta che si verifichi un evento, quindi risponde in qualunque cosa decidiamo attraverso l’uso di altro codice (che è dove entrano in gioco gli oggetti di dominio).

2 oggetti di dominio

Questi possono anche essere chiamati oggetti aziendali o qualcosa di simile. L’idea alla base è questa:

Tutto ciò che facciamo nella programmazione orientata agli oggetti ha lo scopo di risolvere un problema particolare ed è pensato per farlo attraverso un tipo di oggetto che rappresenta un oggetto del mondo reale o almeno un’idea concreta.

Quindi, ogni volta che stai lavorando per fornire una soluzione a qualcuno, le classi che stai scrivendo – gli oggetti che diventeranno quando istanziati – sono gli oggetti di dominio.

Queste sono anche le classi che svolgono il lavoro vero e proprio. Quindi puoi pensarlo in tre componenti:

1. WordPress. L’applicazione principale, ovviamente, che genera l’evento a cui rispondono gli abbonati.
2. Abbonati. L’insieme di classi responsabili dell’ascolto di un evento specifico e quindi della creazione di un’istanza dell’oggetto appropriato per gestire il codice.
3. Oggetti di dominio. Il codice che esegue effettivamente il lavoro di prendere un insieme di dati, operare su di esso e quindi potenzialmente restituire un valore.

Gli oggetti di dominio sono dove risiede il codice per fare effettivamente qualcosa. Gli abbonati sono come la connessione tra WordPress e detta funzionalità.

Gli abbonati dicono "Questo evento si è verificato e questa classe è in grado e responsabile di gestirne i risultati".

Che dire di test e così via?

In precedenza nel post, ho parlato di come gli oggetti di dominio sono correlati agli unit test e ad altre tecniche di programmazione relative al controllo qualità.

Anche se questo non è il post per i dettagli, vale la pena ricordare che mantenere gli oggetti di dominio e gli abbonati disaccoppiati l’uno dall’altro (e, a sua volta, da WordPress) ci consente di creare un’istanza, testare e lavorare con oggetti invocati da iscritti senza dover portare WordPress nel nostro lavoro.

E questo è qualcosa che può essere immensamente utile quando si creano soluzioni più grandi. Ma il succo di come farlo è contenuto per un altro post.