Prototypage rapide avec WordPress : analyse de concept

Dans le post précédent, j’ai commencé à parcourir le processus de prise de l’idée d’un plugin qui le prototype rapidement en quelque chose qui fonctionne dans WordPress. Et bien que cela fonctionne, il ne suit pas nécessairement de principes orientés objet, ni dans un endroit où nous pouvons facilement continuer à ajouter des fonctionnalités.

Non, ce n’est pas un argument pour expliquer pourquoi l’orientation objet est meilleure. Il se trouve que c’est ma façon préférée d’écrire du code, donc je l’aborde de cette façon.

Je sais que l’exemple de code que je donne est simple et je sais qu’on peut faire valoir que quelque chose comme ça peut être laissé tel quel. Mais le but de ceci est de montrer comment prendre un concept, le prototyper, puis le transformer en quelque chose qui suit les principes orientés objet.

Et, d’après mon expérience, il est beaucoup plus difficile de le faire avec un exemple complexe dès le départ. si vous perdez des lecteurs dès le début, alors quel espoir y a-t-il pour eux de comprendre ce qui s’en vient ?

Cela dit, nous allons jeter un œil au code du post précédent et faire une petite analyse de concept dessus pour voir ce qui pourrait bien fonctionner dans une classe et comment nous pourrions commencer à l’organiser en utilisant des classes, espaces de noms, etc.

Analyse conceptuelle

Chaque fois qu’il s’agit de programmation, il est si facile de vouloir se lancer immédiatement dans l’écriture de code, puis de le soumettre jusqu’à ce qu’il fasse quelque chose que nous voulons.

Et une fois que cela fonctionne, nous avons l’impression d’avoir terminé et nous pouvons passer à la tâche suivante. Mais pour les grands projets, ce n’est pas toujours le cas. En fait, il est souvent préférable de faire un peu d’analyse de concept ou d’analyse orientée objet sur votre conception avant d’aller de l’avant.

Se lancer simplement dans le codage n’est pas toujours la meilleure approche.

Un cas à analyser

Exemple concret : au moment d’écrire ces lignes, l’un de mes coéquipiers et moi discutons de l’opportunité d’étendre une classe ou d’écrire une nouvelle classe pour gérer les informations de géolocalisation des données extraites de l’API Google Maps.

Puis-je l’aile et écrire quelque chose qui fonctionne? Bien sûr. Mais s’intégrera-t-il bien à l’application? Non sans analyse de concept, planification et coordination avec le reste du système.

Et c’est bien là le but de l’analyse.

Analyser notre travail

Alors, qu’est-ce que cela signifie pour le plugin que nous avons examiné hier ? En ce moment, nous avons ce qui suit :

• une fonction chargée de créer une meta box et d’en afficher le contenu,
• une fonction d’interrogation de la base de données et de récupération des derniers messages les plus récents,
• une fonction pour afficher les résultats dans la meta box
• une fonction pour afficher un message lorsqu’il n’y a pas de résultats dans la méta-boîte

De plus, un certain nombre de ces fonctions sont liées aux crochets qui font partie de l’API WordPress. A savoir, la fonction de création de la meta box est accrochée à WordPress et sa fonction compagnon de rendu de l’affichage font toutes partie du même composant.

Ensuite, nous avons des fonctionnalités pour interroger la base de données et nous avons des fonctions directement liées aux vues.

Alors, à quoi cela pourrait-il ressembler si nous devions schématiser cela dans diverses classes et fichiers qui aideraient à créer cela d’une manière plus orientée objet?

Pas de solution unique

Il n’y a pas de solution unique et certaines solutions sont beaucoup plus avancées que d’autres. Mais puisque j’essaie de trouver un équilibre ici, je vais aborder cela d’une manière plus simple que de trop travailler avec l’abstraction, l’héritage, les interfaces et tout ça.

Se concentrer sur ce que nous avons

Pour l’instant, concentrons-nous sur les classes individuelles et les responsabilités qu’elles peuvent avoir. Par exemple:

• Je pense que nous allons avoir besoin d’une classe qui représente la méta-boîte. Cela devrait être responsable de la création de la méta-boîte.
• Nous aurons également besoin d’une classe chargée d’afficher le contenu de la méta-boîte. Vous pensez peut-être que l’inclusion d’une fonction dans la classe pour la méta-boîte fonctionne bien. Cela fait; cependant, si vous voulez considérer chaque classe comme ayant une responsabilité unique, nous pouvons créer une classe spécifiquement pour l’affichage et spécifiquement pour la méta-boîte, puis injecter l’affichage dans la méta-boîte lors de l’instanciation. Nous en reparlerons plus tard.

À ce stade, notre diagramme pourrait ressembler à ceci :

Décomposer la méta-boîte.

Ensuite, nous devons considérer les autres fonctionnalités. À savoir, la fonctionnalité d’affichage des résultats dans la méta-boîte et la fonctionnalité d’affichage des résultats lorsqu’il n’y en a pas.

Afin d’afficher quoi que ce soit dans la méta-boîte, nous devons avoir un moyen d’interroger la base de données pour récupérer les résultats. À partir de là, nous devons ensuite pouvoir déterminer s’il y a des résultats, s’il n’y en a pas, puis injecter ces résultats dans la vue.

Compte tenu de ces informations, il semble que nous ayons besoin d’une classe pour interroger la base de données, puis nous avons besoin d’une classe pour diffuser un message dans l’affichage de la méta-boîte.

Peut-être qu’une façon d’organiser les cours ressemblerait à ceci :

Interrogation de la base de données et préparation des messages.

La version finale du diagramme est peut-être un peu à l’étroit, mais nous examinons finalement quelque chose comme ceci :

L’organisation définitive de nos cours.

Aux fins d’explication :

• Le récupérateur de messages demande à la base de données les trois derniers messages les plus récents.
• Le messager de la poste déterminera quel message injecter à l’affichage.
• L’affichage restituera le message qui a été défini.
• La boîte de méta rendra son affichage au navigateur Web.

Nous avons donc essentiellement pris quelques fonctions qui étaient accrochées à WordPress et les avons décomposées en composants qui peuvent communiquer entre eux, chacun étant relativement facile à utiliser et ne faisant pas plus d’un seul travail.

Le convertir en code

Maintenant que nous avons une idée de la façon dont nous pouvons convertir le concept précédent en code, nous verrons comment le faire dans les deux prochains articles.

Notez que la façon dont vous choisissez d’implémenter votre code ou de concevoir vos classes peut être un peu différente de ce que j’ai ci-dessus et vous pouvez avoir des suggestions sur la façon de mieux organiser ce qui est ci-dessus. Si c’est le cas, laissez un commentaire.

Dans le prochain article, nous verrons comment convertir cela en code fonctionnel et, après cela, nous verrons comment l’organiser en espaces de noms appropriés et en organisation de fichiers appropriée.

Messages de la série

1. Prototypage rapide avec WordPress : du concept au plugin
2. Prototypage rapide avec WordPress: analyse de concept
3. Prototypage rapide: Prototyper pour coder, partie 1
4. Prototypage rapide: Prototyper pour coder, partie 2
5. Prototypage rapide : présentation du chargement automatique