Programmation WordPress : Séparer les préoccupations

En ce qui concerne la création de classes pour les plugins WordPress, on m’a demandé pourquoi je m’embêtais à séparer les fonctionnalités en abonnés et en autres classes.

Je pense que c’est une bonne question car elle aide à comprendre deux choses :

1. le rôle d’un abonné en ce qui concerne l’architecture WordPress,
2. le rôle des autres classes en ce qui concerne ce que vous construisez (et comment cela peut aider avec d’autres choses comme les tests unitaires, etc.).

Alors j’ai pensé pourquoi ne pas répondre sous la forme d’un court message? Il documentera le pourquoi derrière le quoi [et cela me donnera un endroit pour mettre à jour si les choses changent à l’avenir].

Programmation WordPress : Abonnés et objets de domaine

Je considère les classes qui ne sont pas des objets de domaine abonnés qui proviennent de l’approche de développement logiciel de la conception dirigée par le domaine.

Cela sort du cadre de cet article, mais il convient de le mentionner, si ce n’est pour aucune autre raison, cela donne un contexte à ce qui serait autrement considéré comme du jargon.

1 Abonnés

Mais d’abord, les abonnés.

Étant donné que WordPress est basé sur un système de hook – un système basé sur le modèle de conception piloté par les événements – il est utile d’avoir une classe qui répond à chaque fois qu’un événement est déclenché.

Cela peut être pour n’importe quel crochet WordPress prédéfini ou pour n’importe quel crochet personnalisé. Ce n’est pas important.

Et je ne veux pas rendre la classe plus compliquée que nécessaire donc j’ai tendance à penser à eux comme ceci :

Un abonné répond chaque fois qu’un événement spécifique se produit.

Et c’est tout. Cet événement peut être quelque chose comme after_theme_setup ou the_content ou même init. Cela n’a pas d’importance.

Il attend qu’un événement se produise, puis répond dans tout ce que nous décidons grâce à l’utilisation d’un autre code (c’est là que les objets de domaine entrent en jeu).

2 objets de domaine

Ceux-ci peuvent également être appelés objets métier ou quelque chose de similaire. L’idée derrière eux est la suivante :

Tout ce que nous faisons dans la programmation orientée objet est destiné à résoudre un problème particulier et il est censé le faire à travers un type d’objet qui représente un objet du monde réel ou au moins une idée concrète.

Ainsi, chaque fois que vous travaillez pour fournir une solution à quelqu’un, les classes que vous écrivez – les objets qu’elles deviendront une fois instanciées – sont les objets du domaine.

Ce sont aussi les classes qui font le travail réel. Vous pouvez donc le penser en trois composantes :

1. WordPress. L’application de base, bien sûr, qui déclenche l’événement auquel les abonnés répondent.
2. Abonnés. L’ensemble des classes responsables de l’écoute d’un événement spécifique, puis de l’instanciation de l’objet approprié pour gérer le code.
3. Objets de domaine. Le code qui effectue réellement le travail consistant à prendre un ensemble de données, à opérer dessus, puis à renvoyer potentiellement une valeur.

Les objets de domaine sont l’endroit où vit le code pour faire quelque chose. Les abonnés sont comme le lien entre WordPress et ladite fonctionnalité.

Les abonnés disent "Cet événement s’est produit et cette classe est capable et responsable d’en gérer les résultats."

Qu’en est-il des tests et ainsi de suite ?

Plus tôt dans l’article, j’ai expliqué comment les objets de domaine sont liés aux tests unitaires et à d’autres techniques de programmation liées au contrôle de la qualité.

Bien que ce ne soit pas l’article pour les détails, il convient de mentionner que le fait de garder les objets de domaine et les abonnés découplés les uns des autres (et, à leur tour, de WordPress) nous permet d’instancier, de tester et de travailler avec des objets qui sont invoqués par abonnés sans avoir besoin d’apporter WordPress dans notre travail.

Et c’est quelque chose qui peut être extrêmement utile lors de la création de solutions plus importantes. Mais l’essentiel de la façon de le faire est contenu pour un autre poste.