Prototypage rapide : Prototyper pour coder, partie 2

Last updated Nov 9, 2022

Teneur

Maintenant, nous sommes organisés (à une exception près)

Le post précédent démontre beaucoup de travail en prenant quelque chose qui était autrefois un prototype rapide et en prenant ce prototype pour coder. Si vous n’avez pas suivi, nous avons fait ce qui suit :

parlé et construit un prototype pour un plugin,
schématisé une approche orientée objet peut fonctionner,
et refactorisé notre prototype en code réel.

À ce stade, il y a quelques autres choses que nous pouvons faire pour améliorer notre code. A savoir, nous pouvons introduire le concept d’espaces de noms. Cela amène l’organisation un peu plus loin et peut rapporter des dividendes pour des projets plus importants.

Voici donc un aperçu de la façon dont cela se déroule dans notre projet actuel.

Prototype à coder : espaces de noms

J’ai couvert les espaces de noms en profondeur dans les articles précédents. Si vous ne l’avez pas lu, je vous le recommande. Revenez ensuite et consultez le reste du message.

Si vous choisissez de sauter l’article, voici une brève définition d’un espace de noms :

Les espaces de noms sont conçus pour résoudre deux problèmes rencontrés par les auteurs de bibliothèques et d’applications lors de la création d’éléments de code réutilisables tels que des classes ou des fonctions…

Et l’idée générale est que nous organisons nos cours en fonction d’une relation logique qu’ils entretiennent entre eux.

De plus, nous organisons également les fichiers dans des répertoires qui correspondent à l’espace de noms. Ce n’est pas quelque chose qui doit être fait, mais je trouve que cela aide d’avoir les classes organisées logiquement sur le disque de la même manière qu’elles sont virtuellement organisées dans l’espace de noms.

Cela dit, organisons les fichiers.

Organiser les fichiers

Plutôt que de commencer par le fichier principal du plugin, commençons par organiser nos fichiers en premier.

Les fichiers Meta Box et Meta Box Display résideront dans un répertoire appelé Display. C’est complètement arbitraire, mais puisque c’est ce que font ces fichiers, il semble logique que ce soit là qu’ils résident.
Nous pouvons également placer les fichiers message-description.php et no-post-list.php dans ce répertoire, mais plaçons-les dans un sous-répertoire appelé Views. Vous voudrez peut-être appeler cela Templates ou Partials ou quelque chose de similaire.
Ensuite, nous avons les classes chargées d’interroger la base de données et la classe chargée de coordonner la messagerie. Plaçons chacun d’entre eux dans Utility. Il y a d’autres endroits où ils pourraient aller, bien sûr, mais rappelez-vous que le but est de montrer comment utiliser les espaces de noms. Donc, si vous vous sentez si enclin, n’hésitez pas à ajuster vos fichiers en fonction de vos goûts.

Si vous avez suivi ce que nous avons ci-dessus, vous devriez avoir une structure de répertoires qui ressemble à ceci :

Une façon d’organiser vos fichiers.

Il est maintenant temps de définir des espaces de noms pour chacune des classes. Puisque nous les avons tous organisés dans leurs répertoires, il sera facile de spécifier un espace de noms ; cependant, il est important de reconnaître que nous aurons besoin d’utiliser le mot-clé use lorsque nous utiliserons des classes situées dans d’autres espaces de noms.

Passons en revue chacun de nos fichiers en commençant par les fichiers dans Utility. Tout d’abord, nous allons commencer par le Post Messenger :

Vous remarquerez que l’espace de noms du fichier apparaît dans l’en-tête avec une déclaration pour utiliser la classe Post Query que nous avons créée. J’ai ajouté le nom de la classe à la fin de l’espace de noms, donc je n’ai pas à l’utiliser dans toute la base de code.

Remarquez que le constructeur ressemble maintenant à ceci :

J’ai ajouté un argument $plugin_dir car nous devons l’utiliser pour afficher correctement les résultats de la requête. Et puisqu’elles résident maintenant dans une zone différente de l’application, les fonctions ressemblent à ceci :

Ensuite, regardons la classe Post Query. Rien n’a beaucoup changé dans cette classe, sauf que nous lui avons donné un espace de noms, et nous avons également mis à jour la requête uniquement pour retirer trois messages (selon this comment ).

Remarquez que dans le code, j’ai également préfixé WP_Query avec une barre oblique car il fait partie de l’espace de noms global.

Passons au répertoire Display et examinons la classe Meta Box. Cela a également reçu un espace de noms et utilise également le nom complet de la classe Meta Box Display que nous examinerons dans un instant.

Notez que ce constructeur accepte également le répertoire du plugin comme argument et le transmet également à la classe Meta Box Display. C’est pour que les fonctions chargées d’afficher les messages puissent être correctement trouvées à leur emplacement dans le répertoire des vues.

Enfin, passons en revue la classe Meta Box Display. Il s’agit d’une classe simple qui inclut l’espace de noms et fait référence au Post Messenger que nous avons examiné ci-dessus.

À ce stade, nous avons bouclé la boucle à travers le plugin. À une exception près: le fichier bootstrap. Nous lui avons ajouté un espace de noms et devons mettre à jour la manière dont il est instancié :

A savoir, nous avons :

défini l’espace de noms,
référencer l’emplacement de la classe Meta Box ,
mis à jour les chemins pour inclure où trouver les fichiers (ce qui peut finalement être fait avec un chargeur automatique),
et mis à jour l’ appel add_action.

Voici la chose à propos de l’appel d’action d’ajout : étant donné que WordPress doit localiser cette fonction et que la fonction réside dans un espace de noms, le nom complet de la fonction doit être identifié afin que WordPress puisse l’invoquer. D’où la nécessité de NAMESPACE dans le nom de la fonction.

Maintenant, nous sommes organisés (à une exception près)

Comme vous pouvez le constater, les espaces de noms et les répertoires qui leur correspondent ajoutent beaucoup d’organisation à un projet. C’est plus facile à suivre, plus facile de comprendre où vont les choses (pour les fichiers existants et nouveaux). Et cela donne moins l’impression d’accumuler de nombreux fichiers en un seul endroit.

Même si une classe est un peu monolithe, elle peut toujours être organisée de manière à faciliter la maintenance.

Cela dit, il y a encore quelque chose que je changerais à propos de ce plugin : faire circuler le répertoire du plugin comme celui-ci n’aide pas à une faible cohésion et il couple plus étroitement les classes ensemble car le fichier d’amorçage doit transmettre une valeur dans une classe qui le transmet à une autre classe qui l’utilise pour charger des fichiers et ainsi de suite.

Alors, y a-t-il des moyens de résoudre ce problème ? Absolument. Et nous y reviendrons peut-être dans le post final.

D’ici là, rappelez-vous que la version la plus récente du plugin est disponible sur la branche master, étiquetée 0.3.0, sur GitHub.

Messages de la série

Source d’enregistrement: tommcfarlin.com