Les deux premiers piliers de la POO
Quand il s’agit de parler de programmation orientée objet (ou POO), vous entendrez probablement parler des trois piliers de la programmation orientée objet ou des quatre piliers de la programmation orientée objet.
Selon votre parcours, vous en avez peut-être déjà entendu parler, vous savez ce qu’ils sont et vous n’avez pas vraiment besoin de trop vous y plonger. Mais si ce n’est pas le cas, je pense que les comprendre est fondamental pour la programmation orientée objet.
Nous avons couvert toute la phase d’ analyse de la programmation orientée objet :
- Analyse, partie 1
- Analyse, partie 2
- Comprendre les attentes des clients
- Énoncé des travaux
- Termes et conditions
Cela dit, entrons dans les discussions sur la conception et la mise en œuvre. Après tout, c’est ce vers quoi beaucoup de gens veulent sauter de toute façon, n’est-ce pas ?
Avant d’écrire le moindre code, j’aimerais faire deux articles sur les quatre points de la programmation orientée objet (car je fais partie de ceux qui souscrivent à l’idée qu’il y en a quatre).
Deux piliers de la POO
Encore une fois, les comprendre est essentiel pour comprendre les fondements de la programmation orientée objet. Sans eux, il sera difficile de naviguer dans le reste de ce qui sera discuté dans les prochains articles.
Sur ce, parlons de chacun d’eux. Nous couvrirons les deux premiers dans cet article et les deux derniers dans le prochain article.
1 Abstraction
D’une manière générale, c’est la clé de l’écriture de code orienté objet. J’entends par là tout ce qui est contenu dans une classe. Nous faisons abstraction de l’idée de quelque chose dans une classe. Dans de nombreux livres, nous verrons des choses comme les animaux ou les voitures représentées comme des classes.
Cela fonctionne, en théorie, mais en pratique, nous ne programmons pas d’animaux ni de voitures (bien que je suppose qu’à ce stade de l’histoire, vous pourriez dire que nous le sommes, mais je m’égare parce que vous voyez ce que je veux dire).
Au lieu de cela, nous allons extraire des idées dans leurs classes. Et il y a une idée clé ici:
Une classe doit représenter un nom.
Autrement dit, vous ne devriez pas avoir une classe qui représente quelque chose comme "Courir". Au lieu de cela, vous pouvez avoir quelque chose qui s’exécute et, par conséquent, les exécutions seraient une méthode. Et c’est la répartition générale du fonctionnement de l’abstraction :
- La chose qui doit être représentée est la classe,
- Ce que fait la chose, ce sont ses méthodes,
- Et la façon dont vous décrivez la chose peut généralement être faite via ses attributs ou ses propriétés.
Cela ne signifie pas que nous n’avons pas de fonctions ou de méthodes qui modifient ses propriétés, mais les trois points ci-dessus sont de bonnes règles de base. Ainsi, lorsque vous concevez une classe, vous pouvez demander des choses comme :
- Est-ce que j’écris quelque chose ?
- Est-ce que j’écris quelque chose à faire ?
- Ou est-ce que j’écris quelque chose qui décrit quelque chose ?
Parce que si vous écrivez une action, c’est probablement fait par quelque chose (parce que les choses agissent – elles font des choses). Et si vous décrivez quelque chose, cela fait probablement référence à quelque chose (à quand remonte la dernière fois où vous n’avez rien décrit ?)
Avoir du sens ?
2 Encapsulation
Donc, si nous écrivons des classes – de bonnes classes – alors nous devons les écrire de manière à encapsuler correctement leurs données. Et l’encapsulation n’est vraiment qu’un «grand» mot qui fait référence à l’idée de gérer ses responsabilités (ou de garder une trace de ses données).
Ainsi, par exemple, si nous écrivions une classe pour représenter un article WordPress, nous aurions une classe nommée Post avec des propriétés telles que publier, mettre à jour, supprimer, postData, publierDate, lastUpdatedData, deleteDate et ainsi de suite.
Ensuite, nous aurions des fonctions spécialement conçues pour agir sur une instance de la classe Post.
Par exemple, nous pouvons…
- publier,
- mettre à jour,
- ou supprimer un message
Ces méthodes seront probablement exposées de manière à ce que d’autres classes puissent en tirer parti. De plus, ces méthodes tireront probablement également parti d’autres propriétés telles que le publishDate ou le deleteDate.
Et c’est là que la notion de visibilité entre en jeu. Dans la programmation orientée objet, l’encapsulation fait non seulement référence à l’idée des informations contenues dans une classe, mais également à la manière dont elle expose les données.
Celles-ci se font de trois manières qui sont toutes définies ci-dessous :
- les propriétés et les fonctions publiques sont disponibles pour que n’importe qui les utilise ; cependant, les propriétés publiques ne sont généralement pas exposées. Au lieu de cela, nous nous assurons qu’ils peuvent être modifiés par une méthode publique.
- les propriétés et fonctions protégées sont disponibles pour être utilisées par la classe et toute autre classe qui en hérite des informations. Cela sera discuté plus en détail dans le prochain post.
- les propriétés et fonctions privées sont celles exclusivement destinées à être utilisées dans le contexte d’une classe donnée. Il peut s’agir de propriétés utilisées pour suivre les statuts internes ou de méthodes utilisées pour fonctionner en tant que fonctions d’assistance pour que les fonctions publiques terminent leur travail.
Au fur et à mesure que nous poursuivrons cette série, nous verrons le rôle que chacun de ces éléments joue lors de la rédaction de classes claires, faciles à suivre et bien architecturées.
Pour l’instant, cependant, il est important de comprendre que ces mots, public, protected et private, sont appelés modificateurs de visibilité car, comme vous pouvez le constater, ils gèrent la visibilité d’une méthode ou d’une propriété par rapport à sa classe et au classes qui en héritent et qui interagissent avec lui.
En parlant d’héritage, j’en parlerai dans la prochaine partie de cette série.
Abstraction, encapsulation et WordPress
La mauvaise nouvelle: Cours sur WordPress
Voici le problème : dans WordPress, nous voyons souvent des classes très, très volumineuses. Ce n’est pas une bonne chose. En fait, ce sont des anti-modèles appelés god-classes (l’idée étant que vous avez une seule classe qui sait tout).
Et lorsque vous avez une classe divine, cela semble pratique car vous pouvez déposer toutes les fonctionnalités au même endroit. Mais
- c’est difficile à tester,
- il n’est pas à l’échelle,
- il ne fonctionne pas bien avec une autre classe (sans parler des classes ou des bibliothèques tierces),
- il ne s’adapte pas bien au changement.
En fin de compte, lorsque vous faites cela, vous ne faites pas de programmation orientée objet. Vous prenez des fonctions et les jetez dans une classe. Et nous voulons nous en sortir.
La bonne nouvelle: écrire des cours sur WordPress
Cela soulève cependant une question: pourquoi essayer d’apprendre la programmation orientée objet avec WordPress si ce n’est pas un exemple solide de programmation orientée objet ?
C’est parce que vous pouvez toujours écrire du bon code orienté objet sur WordPress. Il peut toujours bien interagir avec WordPress, et il peut toujours bien jouer avec de nombreux autres aspects de WordPress.
Je sais que cela semble contre-intuitif, mais à mesure que nous approfondissons l’écriture de code orienté objet sur WordPress, cela devrait devenir clair.