Widgets WordPress : détecter la programmation orientée objet
Si vous n’avez pas lu le premier article de cette série, je le recommande, car nous commençons à écrire du code orienté objet pour WordPress grâce à l’utilisation de l’ API Widgets.
La série va capturer quelques choses:
- vous montrer le squelette de base d’un widget et pourquoi il est orienté objet,
- discuter des choses que vous devriez être en mesure de remarquer et pourquoi
- mettez d’abord à jour le Widget Boilerplate directement sur ce site, puis envoyez-le à GitHub,
- construire un widget en utilisant l’API avec le passe-partout comme base de notre travail.
Mais avant de faire cela, je veux m’assurer que tous ceux qui lisent ceci connaissent les principes fondamentaux de la programmation orientée objet et disposent de tout le nécessaire pour créer une solution orientée objet pour WordPress.
À cette fin, je recommande ce qui suit :
- Deux piliers de la programmation orientée objet: partie 1 sur 2
- Deux piliers de la programmation orientée objet: partie 2 sur 2
- Classes abstraites, partie 1 – Comportement d’abstraction
- Classes abstraites, partie 2 – Classes abstraites et interfaces
- Le Développeur WordPress Indépendant
Si vous avez lu tout ce contenu, tant mieux. Vous allez être bien préparé pour cet article et les articles à venir. Sinon, il peut y avoir des trous dans le reste de ce que vous êtes sur le point de lire, mais l’essentiel du message doit être suffisamment clair.
Quel est le problème, exactement ?
Voici le truc : la semaine dernière, j’ai partagé un peu de code avec des informations sur l’ API Widgets. Je vais y revenir un peu plus dans cet article avant d’entrer dans la partie la plus intensive en codage pour deux raisons :
- Je veux que tous ceux qui lisent ceci soient sur la même page en ce qui concerne l’écriture de code orienté objet (à tout le moins, dans ce contexte),
- Je reconnais que les gens viennent d’horizons différents et je veux m’assurer que nous sommes tous sur la même page autant que possible avant de continuer.
Si vous avez de l’expérience dans l’écriture de code orienté objet, en particulier à un niveau avancé, cela peut vous sembler plus simple ; sinon, j’espère que cela vous fournira tout ce dont vous avez besoin pour détecter les pratiques orientées objet non seulement concernant cette API, mais également lors de la lecture du code des autres.
Comment détecter la programmation orientée objet
Peut-être une première question naturelle est pourquoi devons-nous être capables de détecter, lire ou comprendre la programmation orientée objet avant de l’écrire réellement ?
Un mot sur le mauvais code
La réponse courte à cela est la suivante :
Vous n’en avez pas besoin, mais c’est utile. Si vous êtes capable de lire la programmation orientée objet, vous aurez une longueur d’avance en tirant parti de ce qu’elle offre comme paradigme, car vous allez vous appuyer sur les stratégies et le travail effectué par d’autres dans d’autres projets.
Cela ne veut pas dire que nous ne lirons pas le mauvais code, mais nous ferons tout notre possible pour identifier le mauvais code, identifier les zones problématiques, puis faire ce que nous pouvons pour éviter de l’incorporer dans notre travail.
Pour l’instant, examinons l’ API Widgets pour voir ce que nous pouvons faire pour détecter la programmation orientée objet.
Retour à la programmation orientée objet
Dans le post précédent, j’ai souligné deux choses qui indiquent que l’API est orientée objet (au moins dans une certaine mesure) :
- l’utilisation du mot clé extend,
- fonctions que nous devons implémenter.
La raison pour laquelle je souhaite revenir sur ce sujet est qu’il identifie deux éléments clés qui font partie des principes fondamentaux orientés objet : l’ héritage et l’implémentation de fonctions (qui font souvent partie de classes abstraites ).
Une note avant de regarder ce qui précède:
Lorsque vous regardez la source de la classe WP_Widget, vous remarquerez qu’il n’y a pas de méthodes abstraites. Mais certaines des fonctions que nous devons implémenter, que je mentionnerai plus tard dans cet article, sont des candidats de choix pour les méthodes abstraites. Et je vais discuter pourquoi, aussi.
Séparons les sujets ci-dessus en deux sections distinctes : Héritage et Abstractions.
Héritage
J’ai couvert l’héritage est une profondeur relative dans le post précédent, donc je n’insisterai pas sur le point ici. Je vais offrir quelques mots, mais je suis beaucoup plus intéressé à discuter de l’abstraction, ce que je ferai dans un instant.
Avant d’aller trop loin dans cela, cependant, veuillez vous référer au code suivant :
<?php
class AcmeWidget extends WP_Widget
{
public function __construct()
{
}
public function widget($args, $instance)
{
}
public function form($instance)
{
}
public function update($newInstance, $oldInstance)
{
}
}Mais d’abord, nous pouvons reconnaître que toute classe qui implémente l’API Widgets doit utiliser l’héritage simplement à cause du mot clé extend.
Cela signifie qu’il y a un niveau de fonctionnalité dont nous allons hériter (ou obtenir gratuitement) et il y a un niveau de fonctionnalité que nous devons implémenter par nous-mêmes.
Du manuel PHP :
Par exemple, lorsque vous étendez une classe, la sous-classe hérite de toutes les méthodes publiques et protégées de la classe parent. À moins qu’une classe ne remplace ces méthodes, elles conserveront leur fonctionnalité d’origine.
Cependant, lorsque vous héritez des fonctionnalités d’une classe, vous pouvez trouver qu’il est important d’appeler strictement le constructeur du parent (dans notre fonction __construct ).
Mais cela soulève ce que je pense être l’un des problèmes les plus importants avec l’héritage en PHP (et la raison pour laquelle je voulais inclure cette section): Avons-nous besoin d’appeler explicitement le constructeur parent ?
Toujours selon le manuel :
Les constructeurs parents ne sont pas appelés implicitement si la classe enfant définit un constructeur. Pour exécuter un constructeur parent, un appel à parent :: __construct() dans le constructeur enfant est requis. Si l’enfant ne définit pas de constructeur, il peut être hérité de la classe parent comme une méthode de classe normale (si elle n’a pas été déclarée comme privée).
Mais nous pouvons simplifier cela. C’est peut-être plus facile à retenir :
- Si notre classe utilise l’héritage mais ne définit pas de constructeur, le constructeur parent est appelé.
- Si notre classe utilise l’héritage mais définit un constructeur, la construction parent doit être explicitement appelée.
Ou peut-être encore plus simplement :
- Si notre classe ne définit pas de constructeur, le code sera par défaut le constructeur des parents.
Avoir du sens ? En bref, si nous définissons nos propriétés, notre initialisation et notre code dans un constructeur, la première ligne du constructeur de notre classe devrait être un appel au constructeur parent.
Abstraction
Pour être absolument clair, le code source de la classe WP_Widget n’inclut pas de méthodes abstraites. Cela est en partie lié à la manière dont la classe est construite, en partie à la rétrocompatibilité et aux fonctionnalités de PHP5.
Cela ne signifie pas pour autant que nous ne pouvons pas identifier quelles fonctions pourraient être marquées comme abstract. En fait, je pense que cela explique quelles classes doivent être rendues abstraites. Mais d’abord, définissons les fonctions abstraites.
Lors de l’héritage d’une classe abstraite, toutes les méthodes marquées abstraites dans la déclaration de classe du parent doivent être définies par l’enfant ; de plus, ces méthodes doivent être définies avec la même visibilité (ou une visibilité moins restreinte).
Lorsque vous regardez la source de notre widget :
<?php
class AcmeWidget extends WP_Widget
{
public function __construct()
{
}
public function widget($args, $instance)
{
}
public function form($instance)
{
}
public function update($newInstance, $oldInstance)
{
}
}Je pense qu’il est juste de dire que la fonction de formulaire pourrait être marquée comme abstraite car elle est unique à notre implémentation. Une autre façon de penser aux fonctions abstraites du point de vue de la programmation est de vous demander : quelles fonctions nécessiteront une fonctionnalité unique ?
Et dans ce cas, la fonction de formulaire est précisément cela, car chaque widget sera unique et différent en ce qui concerne ce qu’il affiche. La fonction de widget peut également être marquée comme abstraite car elle affiche le contenu du widget. Ce contenu est, naturellement, basé sur la fonctionnalité que nous avons implémentée dans notre implémentation.
De plus, le code source de la classe WP_Widget lui-même indique :
la fonction WP_Widget::widget() doit être remplacée dans une sous-classe.’
C’est précisément le type de fonction qui doit être marqué comme abstrait. Parce que PHP lancera une erreur si une fonction est marquée comme abstraite et non implémentée. Nous n’avions pas besoin d’ appels de fonction die ou quoi que ce soit de ce genre.
Les autres fonctions, cependant, n’auront pas nécessairement besoin d’être marquées comme abstraites et voici pourquoi :
- __construct appellera le constructeur du parent, au niveau le plus basique, et cela est nécessaire pour initialiser la classe de base. N’oubliez pas, cependant; nous pouvons ajouter nos propriétés à cette méthode qui sont uniques à notre classe.
- update utilise les fonctionnalités de la classe parent pour la sérialisation des informations.
Ainsi, il nous reste deux fonctions qui pourraient être marquées comme abstraites dans une itération plus moderne de la classe.
Suivant
À ce stade, nous devrions tous être sur la même page en ce qui concerne le code orienté objet. Au moins autant que nous puissions passer à travers une série de billets de blog.
À partir du prochain article, nous allons revenir à l’écriture de code.
Autrement dit, nous allons revoir le WordPress Widget Boilerplate et je vais le refactoriser dans son état actuel pour adopter des normes PHP plus modernes.
Je vais partager les modifications que j’apporte, les justifications du pourquoi, puis je parlerai également du type de widget que nous allons construire sur la base du passe-partout (et nous pouvons le faire).