Singletons dans WordPress, revisités (Un temps et un lieu ?)
Avant de commencer un article sur l’utilisation de singletons dans WordPress (ou, plus exactement, le Singleton Pattern ), je veux m’assurer que vous avez lu les deux articles suivants :
- Le clonage en PHP, ou pourquoi votre singleton pourrait tuer WordPress par Thomas Scholz
- Les singletons et leur utilisation dans WordPress par Carl Alexander
Ces deux articles fournissent une perspective extrêmement précieuse sur ce modèle et les dangers de l’utiliser chaque fois que nous l’utilisons tout au long de notre travail dans WordPress ; Cependant, cela signifie-t-il que nous devrions complètement les éviter ?
Je ne pense pas.
Là encore, je reconnais également que les articles ne disent pas de les éviter complètement. Ils donnent des arguments solides sur la façon de les utiliser et les dangers de les utiliser si vous choisissez de le faire.
Et même si je les ai certainement utilisés dans le passé, j’ai généralement arrêté. Cependant, je suis récemment tombé sur un cas d’utilisation pour un projet dans lequel je pense que c’est acceptable.
Vous utilisez toujours des singletons dans WordPress ?
Afin de donner une raison pour laquelle je considère même ce modèle particulier, je pense qu’il vaut la peine de comprendre d’abord le cas d’utilisation. Pour faire simple :
- Il existe une page d’administration qui permet à l’utilisateur de sélectionner la manière dont il souhaite afficher les dates sur le front-end du site.
- Lorsque l’utilisateur enregistre l’option, il écrira le format basé sur PHP pour la date dans un tableau de WordPress.
- Lors du rendu d’une date, la valeur sera extraite de la base de données et appliquée à la date à rendre.
Et pour ceux qui sont curieux, il n’y a qu’une poignée – disons quatre ou cinq – façons dont nous permettons à l’utilisateur d’afficher la date.
Parce que ce projet particulier permet aux utilisateurs d’importer des CSV de données (qui incluent des dates) et qui leur permettent de restituer les données des CSV bien que dans un format différent, il convient de noter qu’il y a une bonne quantité de formatage de date qui se produit sur le back-end.
Naturellement, une question se pose :
Pourquoi ne pas simplement formater la date à laquelle l’utilisateur importe son CSV ?
Et c’est parce que l’utilisateur peut choisir de changer la façon dont la date est rendue après l’importation du CSV.
Cela dit, il existe un tout autre mécanisme dans le plugin chargé de valider, de nettoyer et d’écrire les entrées de l’utilisateur dans la base de données.
Mais quand vient le temps de saisir des valeurs de la base de données, en particulier lorsqu’il s’agit de lire une valeur dans une table de base de données, et de le faire à plusieurs points de l’application, ne serait-il pas logique d’avoir un seul point de dont la valeur peut être dérivée?
Un aperçu de haut niveau de la façon dont cela fonctionne.
Ou, une autre façon de le dire, n’est-il pas logique de changer un endroit dans l’application qui peut facilement se répercuter sur le reste de l’application plutôt que de rechercher tous les endroits possibles de :
- lecture de l’option,
- s’assurer qu’il est réglé,
- définir une valeur par défaut si elle n’est pas définie,
- et retourner la valeur?
Et c’est là que je vois une utilisation valide d’un singleton dans WordPress entrer en jeu: un moyen de lire des données à plusieurs points de l’application. Cela entraîne cependant certaines implications :
- la classe n’a pas besoin d’être instanciée plus d’une fois (je veux dire, c’est toute l’idée du singleton),
- il ne traitera pas de données modifiables,
- il ne s’agira pas d’écrire des informations ou de manipuler des informations.
En d’autres termes, il est seul responsable de la récupération des informations et de leur restitution. C’est ça. Rien d’autre.
Un exemple d’implémentation
Alors, à quoi cela pourrait-il ressembler? Voici une implémentation approximative à des fins de conversation :
<?php
class Date_Formatter {
private static $instance;
private function __construct() {
}
private static function get_instance() {
if (null === self::$instance) {
self::$instance = new self;
}
return self::$instance;
}
public static function get() {
self::get_instance();
$default_format = 'm/d/Y';
$format = get_option( 'yhd_directory_importer', false );
if (false === $format) {
return $default_format;
}
$format = $format['date'];
$format = (isset( $format) && isset( $format['format']) )? $format['format']: $default_format;
return $format;
}
}
Comme vous pouvez le voir, il remplit tous les points ci-dessus. Autrement dit, il lit les données, définit une valeur par défaut, puis la renvoie.
Cette classe ne fait rien d’autre que lire et renvoyer un ensemble de données très spécifique.
Une mise en garde sur la mise en cache
Évidemment, puisque cette classe lit les données de la base de données, elles peuvent – et éventuellement devraient – être mises en cache. Le but de cet article, cependant, n’est pas d’entrer dans les transitoires, les expirations et de travailler sur toutes ces nuances.
Au lieu de cela, il s’agit d’évaluer s’il s’agit ou non d’un cas d’utilisation valide pour implémenter un singleton dans WordPress.
Attendez, ça ne doit pas être comme ça !
Je sais je sais. Psy! Je pense que c’est la bonne terminologie, mais restons professionnels.
Jusqu’à présent, tout l’article expliquait pourquoi vous voudriez peut-être étudier l’utilisation de singletons dans WordPress afin d’avoir un moyen de récupérer facilement des informations en utilisant des principes orientés objet.
Mais je ne pense toujours pas que l’utilisation d’un singleton dans WordPress soit nécessaire ici. À tout le moins, je pense qu’une fonction statique est très bien. Et la seule raison pour laquelle je pense que ça va, c’est parce que créer une instance de la classe chaque fois que vous avez besoin d’accéder à une fonction qui récupère des données qui ne changeront pas dans la classe est exagéré.
Alors à quoi ça ressemble?
<?php
class Date_Formatter {
public static function get() {
$default_format = 'm/d/Y';
$format = get_option( 'yhd_directory_importer', false );
if (false === $format) {
return $default_format;
}
$format = $format['date'];
$format = (isset( $format) && isset( $format['format']) )? $format['format']: $default_format;
return $format;
}
}
Et cela, je crois, est une meilleure solution que la mise en œuvre d’un modèle de conception arbitraire lorsqu’il n’est pas du tout nécessaire.
Mais je suis ouvert à être convaincu du contraire.
Des réflexions de développeurs plus expérimentés ?
J’ai entendu d’un ami et d’un pair que la simple utilisation d’une fonction d’espace de noms pourrait même être la voie à suivre. De toute évidence, il existe une variété de façons d’aborder cela.
Et avec cela, je suis intéressé d’entendre le reste d’entre vous sur la façon dont vous pouvez refactoriser cela encore plus loin. Je ne suis pas tellement concerné par l’implémentation de la fonction get puisqu’elle est principalement mise en place pour la démo.
Au lieu de cela, je suis intéressé par les moyens de gérer cela en dehors de ce qui est présenté ici. Ou plutôt, juste votre point de vue sur ce que vous voyez.