Programmation orientée objet dans WordPress : analyse, partie 1
Lorsque j’ai commencé à proposer des adhésions sur ce site, je savais que la première chose que je voulais aborder était une introduction à la programmation orientée objet.
C’est quelque chose qui semble être intéressant pour la plupart des gens qui travaillent dans WordPress, mais il y a un problème qui détourne beaucoup de gens ou génère de mauvais résultats :
La programmation orientée objet peut se compliquer rapidement. Et cela devient démotivant.
Voici ce que je veux dire: supposons que vous êtes un développeur WordPress qui commence à faire des recherches sur la programmation orientée objet. Il commence par parler de classes, de constructeurs et de fonctions, et tout semble bien.
Mais ensuite, il entre rapidement dans:
- méthodes privées et protégées,
- héritage,
- polymorphisme,
- modèles de conception,
- injection de dépendance,
- référentiels,
- etc.
Ça fait boule de neige, non? Et ce n’est pas du tout comme ça que ça doit être, mais il est difficile de trouver une bonne introduction à part quelques ressources qui existent.
Cela dit (et servant de toile de fond à l’endroit où je me dirige), je voulais créer une série de contenus pour ceux qui :
- sont vraiment intéressés par la programmation orientée objet,
- ne savez pas par où commencer,
- souhaitent développer leurs compétences,
- veulent repartir de zéro sans dégénérer trop rapidement en matière plus compliquée.
Et c’est ce que je commence aujourd’hui et dans le premier grand sérieux prévu pour les membres. Avec tout cela dit, commençons.
Plus précisément, commençons à parler de programmation orientée objet, d’analyse, de conception et pourquoi elle devrait commencer par là.
Programmation orientée objet : analyse
Lorsqu’il s’agit d’écrire du code, il existe actuellement trois façons populaires de le faire :
Chaque fois que nous travaillons et lisons du code WordPress, vous allez lire une combinaison de code procédural et de code orienté objet.
Il y a plusieurs raisons pour lesquelles c’est le cas, mais cela sort du cadre de notre discussion.
C’est parce que WordPress est construit avec les deux et parce que certains aspects du développement WordPress peuvent être écrits avec du code procédural, comme les plugins et les thèmes, et d’autres nécessitent un développement orienté objet comme les widgets.
Analyse et conception
Très souvent, la première chose que nous voulons faire, en tant que développeurs (en herbe ou non), est de nous lancer immédiatement dans l’écriture de code. Je reçois aussi. C’est marrant. Nous avons une idée, nous voulons lui donner vie, nous voulons commencer à l’utiliser et nous voulons la montrer à d’autres personnes.
Voici le problème avec cela, cependant: nous passons souvent directement à l’écriture de code pour essayer de faire en sorte que le projet fasse ce que nous voulons qu’il fasse.
S’il s’agit d’un projet simple (et je veux dire très simple), alors ce n’est pas si grave. Honnêtement, je l’ai fait (et GitHub en est la preuve). Mais en ce qui concerne le travail que nous faisons chez Pressware ; c’est une autre histoire.
Quand il s’agit de projets comme celui-là, nous voulons faire un peu d’analyse et de conception avant d’écrire du code.
Ce qui soulève la question, qu’est-ce que l’analyse et la conception orientées objet ?
Une analyse
En bref, pensez-y de cette façon:
L’analyse est le processus qui consiste à prendre l’idée que le client ou que vous avez et à creuser ce qui doit vraiment être construit.
Cela peut vous aider à déterminer quel est le coof de l’application et ce qui n’est pas nécessaire pour la première version de l’application. J’aime les étiqueter en ce qui concerne les "incontournables" et quels sont les "sympa à avoir".
Une bonne règle de base est la suivante :
- les incontournables sont les choses qui sont au cœur de l’application et doivent entrer dans la première itération du projet,
- les choses agréables à avoir sont les choses que nous pouvons éventuellement y intégrer
En fin de compte, cela nous aide à travailler vers une première version solide pour le client. Un exemple est peut-être pour WordPress :
- La première version de WordPress avait-elle besoin d’avoir une API de plugin ou avait-elle simplement besoin d’avoir la possibilité pour les gens d’écrire des articles et de les publier sur le Web ?
Si vous construisez une plate-forme pour les blogs, doit-elle être extensible dès la première version ? Ce n’est rien de plus qu’un exemple, mais vous voyez l’idée.
Qu’est-ce qui rend l’analyse si difficile ?
Je pense que cela a souvent à voir avec les personnages.
Par exemple, nous, en tant que programmeurs, pensons qu’un projet doit toujours faire ce que veut le client. La vérité est que ce n’est pas toujours le cas.
Je veux dire, éventuellement, ça pourrait l’être, mais la première version du projet n’a pas nécessairement besoin d’être ainsi.
De plus, l’un des principes de la programmation orientée objet est que nous n’écrivons pas beaucoup de code en double. Mais cela peut être très difficile à faire si une analyse adéquate n’a pas été effectuée.
Enfin, les plus expérimentés diront qu’un bon logiciel utilisera des principes éprouvés – qu’il s’agisse de modèles de conception ou non – mais qu’il est capable d’être modifié facilement au fil du temps. Cela, dans un sens, se développe organiquement.
Alors, que devons-nous faire ?
Dans le prochain article, je vais parler de trois choses que nous pouvons faire, en tant que développeurs, pour nous assurer que le logiciel que nous construisons pour nous-mêmes ou pour les autres nous emmène dans la bonne direction.
Je ne dirai pas que c’est une solution miracle parce que je ne crois pas que cela existe, mais je dirai que c’est une approche assez forte que j’ai trouvé d’autres à utiliser et bien que moi-même et qui mène à une assez bonne direction en termes d’analyse orientée objet.
Cela nous mènera éventuellement à la conception. Mais nous n’en sommes pas encore là.