Partie 4 – WordPress et la programmation orientée objet : un exemple WordPress – Conception

À ce stade, nous avons des exigences clairement définies telles qu'elles ont été décrites dans la partie 3 de cette série (consultez-les ici si vous les avez manquées).

Il est maintenant temps de commencer à réfléchir à la conception de notre nouveau plugin amélioré !

Nous vous rappelons que cette étape peut vous prendre beaucoup de temps lorsque vous l'essayez sur vos propres projets. Vous n'obtiendrez probablement pas tout correctement du premier coup non plus. Il y a de fortes chances que vous proposiez un design, que vous commenciez à le mettre en œuvre, puis que vous réalisiez que vous devez revenir en arrière et repenser votre approche.

Cela en vaut vraiment la peine, alors prenez autant de temps que nécessaire pour que tout soit parfait. Un projet bien structuré facilitera sa maintenance et son extension, et même la réutilisation de son code dans d'autres projets, donc à long terme, c'est une bonne utilisation du temps.

Ensuite, nous nous concentrerons sur certaines parties clés du plugin et discuterons de la façon dont nous avons conçu notre conception.

Disséquer la page des paramètres

Examinons de plus près la page d'administration du plugin.

Vous remarquerez qu'il y a un titre ("Paramètres de limitation des tentatives de connexion"), plusieurs sections contenant certains champs et un bouton "Modifier les options" en bas de la page.

Chaque section se compose d'un titre, comme "Statistiques", et de quelques champs.

Chaque champ a un titre sur la gauche et le reste de son contenu sur le côté droit. Il y a des champs de texte, des boutons radio et des cases à cocher et, certains d'entre eux, comme "Total Lockouts", n'affichent que des informations et ne peuvent pas être directement modifiés par l'utilisateur administrateur.

Certains champs incluent également une description, comme le champ "Connexion au site", mais pas tous.

Avec ce qui précède à l'esprit, nous devons le décomposer en éléments conceptuels qui deviendront plus tard des classes.

L'API WordPress Settings nous permet d'enregistrer des pages de paramètres, des sections dans ces pages et des champs dans les sections :

Pages → Sections → Champs

Nous avons pensé, pourquoi ne pas ajouter une "couche" de plus, les éléments, afin de rendre notre plugin plus facile à étendre à l'avenir.

Pages → Sections → Champs → Éléments

Ainsi, les pages et les sections sont ce que nous avons déjà expliqué ci-dessus, et les champs contiendront des éléments de tout type de contenu sur le côté droit.

En tenant compte de tous ces différents types d'éléments, nous avons opté pour une classe Element et plusieurs classes, en l'étendant, pour les cases à cocher, les boutons radio, les chiffres, etc. qui rendront une sortie différente.

Nous pourrions également avoir besoin d'ajouter plus de pages et de sections à l'avenir. Il est donc probable que nous devions étendre ces classes de page et de section d'administration.

Il en va de même pour les champs. Les classes pour « Verrouillages totaux », « Verrouillages actifs », etc. étendront la même classe (parente).

Voici un visuel simplifié qui illustre ces relations :

Bien sûr, tous les « composants » ne sont pas inclus dans le diagramme.

Une structure comme celle-ci rend le plugin plus facile à étendre ; nous pouvons facilement ajouter un champ, un élément ou une section si le besoin s'en fait sentir. Nous pourrons facilement ajouter plus de composants (champs, éléments ou sections) en créant de nouvelles classes enfants, sans avoir à modifier celles qui existent déjà.

Pensée et abstraction

C'est maintenant le moment idéal pour commencer à réfléchir à ce que font les différents composants de notre plugin. Pendant la phase de conception, nous n'avons pas besoin d'entrer dans les détails sur le fonctionnement de quelque chose.

Par exemple, considérez tous les éléments, tableaux, statistiques et à peu près tout ce qui va être affiché à l'utilisateur. Ils peuvent être des composants séparés sans rien en commun, mais finiront tous par produire une sortie. Par conséquent, certaines fonctionnalités seront communes à des composants qui n'ont par ailleurs aucun rapport. Bien entendu, cela s'applique également au reste de nos composants.

Dans le visuel ci-dessus, nous voyons comment une interface d'interface utilisateur est implémentée par plusieurs classes.

Faites attention au fait que l'interface utilisateur est implémentée par les classes Statistics, Lockout Logs, Table et Element qui sont appelées classes parentes . Il n'est pas nécessaire que les classes Radio/Number/Checkbox Element implémentent directement l'interface, car elles héritent de toutes les interfaces de leur classe parent. Cependant, une classe enfant peut remplacer une méthode de sa classe parent.

Puisque nous savons que notre plugin va gérer les paramètres, nous pouvons supposer en toute sécurité que nous lirons et écrirons leurs valeurs. C'est-à-dire pouvoir obtenir , définir et supprimer des options.

Toutes ces actions seront regroupées dans une classe. Nous stockerons probablement nos options dans la base de données WordPress ou quelque chose comme ça. Pour l'instant, nous n'avons pas à nous soucier de comment ou où nous allons stocker nos données.

Nous pouvons garder à l'esprit l'abstraction des options get/set/remove, en simplifiant les choses conceptuellement, et continuer à concevoir notre plugin.

Fichier de plugin principal

Ici, nous fournirons des informations sur le plugin à WordPress via le commentaire d'en-tête et effectuerons une initialisation. Nous allons organiser notre code, en enveloppant tout dans une petite classe.

Selon la façon dont les classes de notre plugin fonctionneront ensemble, la classe principale devra instancier la plupart d'entre elles. Pour autant que nous sachions, cela inclura des classes liées aux options, aux pages d'administration, aux tentatives et aux verrouillages.

Classes potentielles

Nous avons pris un peu de temps pour essayer de déterminer les classes dont nous aurons besoin et nous nous sommes retrouvés avec une liste comme suit :

• Nouvelles tentatives
• Verrouillages
• Biscuits
• Messages d'erreur
• Notifications par email
• Avis d'administration
• Boutons
• Journaux de verrouillage
• Verrouillages actifs/total
• adresse IP

Gardez à l'esprit qu'il n'y a pas une seule façon "correcte" de structurer votre plugin. Comme pour la plupart des choses dans le développement de logiciels, il existe plusieurs façons, tout aussi valables, de résoudre un problème.

Dans la section "Général", par exemple, les relations entre nos classes ressembleraient à ceci :

La section "Statistiques" ressemblera à ceci :

Enfin, les "Journaux de verrouillage" seront très similaires aux "Statistiques":

Conclusion

Jusqu'à présent, nous avons défini nos exigences et pensé à un design pour notre nouveau plugin amélioré. Nous avons expliqué comment nous avons créé notre structure et avons également fourni quelques schémas simples montrant comment nos classes seront liées les unes aux autres.

Cliquez ici pour lire la partie 5 de notre série sur la programmation orientée objet

Voir également

• WordPress et la programmation orientée objet - Un aperçu
• Partie 2 – WordPress et la programmation orientée objet : un exemple concret
• Partie 3 – WordPress et la programmation orientée objet : Α Exemple WordPress – Définition de la portée