Modèles de conception dans WordPress Le modèle Singleton

Tout au long de cette série, nous examinons l’importance des modèles de conception et les rôles qu’ils jouent dans le développement WordPress..

Dans le premier article de la série, nous avons mené une enquête de haut niveau et avons même examiné le modèle d'observateur pour voir comment il était possible d'enregistrer diverses fonctions ou objets avec certains événements se produisant au cours du cycle de vie d'une application..

Dans cet article, où va jeter un coup d'oeil au motif Singleton.

Plus précisément, nous allons examiner la définition du motif et son fonctionnement, nous allons passer en revue un diagramme de l'architecture du motif, nous allons couvrir un exemple de code pour le motif, et ensuite nous discuterons des avantages du motif en ce qui concerne le développement WordPress.

Le modèle Singleton

Wikipedia définit le modèle Singleton comme suit:

En génie logiciel, le motif singleton est un motif de conception qui limite l'instanciation d'une classe à un seul objet..

Voici peut-être un moyen plus simple d’expliquer le modèle: Le modèle Singleton garantit qu’une classe ne peut avoir qu’une instance et fournit un moyen unique de récupérer une instance de sa propre.

Alors, pourquoi est-ce important dans WordPress?

En ce qui concerne le développement de thèmes, je ne vois personnellement aucune utilité, sauf si vous regroupez un type de classe ou de bibliothèque d'assistance avec votre thème; cependant, si vous construisez des plugins, cela peut être exceptionnellement utile.

À l'heure actuelle, il n'existe qu'une poignée de méthodes pour instancier des plugins (à l'exception des widgets - c'est un autre sujet) dans WordPress:

Vous pouvez instancier le plugin au bas de votre fichier de plugin, mais cela peut conduire à un objet orphelin
Vous pouvez coller le plugin dans le PHP $ GLOBALS collection, mais cela peut être dangereux car vous pourriez jeter quelque chose qui existe déjà ou rendre la collection inutilement plus grande
Si vous l'instanciez avec, par exemple, chaque chargement de page, les données ne sont pas conservées sauf si vous sérialisez et martelez la base de données à chaque fois que le plugin est instancié.

Aucune de ces réponses ne sont particulièrement bien stratégies (bien que vous puissiez faire valoir qu'elles fonctionnent toutes).

Cependant, nous nous soucions plus que de simplement faire fonctionner quelque chose, non? Nous voulons que cela fonctionne et nous voulons une solution élégante au problème. C’est là que les patrons de conception - plus précisément le Singleton Pattern - entrent en jeu.

À quoi il ressemble

Tout d’abord, examinons un diagramme du motif Singleton. Regardez le diagramme ci-dessous, puis nous parlerons des détails après l'image:

Voici donc les principales caractéristiques du motif Singleton:

Il existe une variable d'instance statique privée définie dans les attributs et utilisée pour gérer une référence à la classe.
Le constructeur a été marqué comme privé
Il y a une fonction statique publique nommée get_instance qui est utilisé pour renvoyer une instance de la classe

Rien aussi compliqué, mais je pense que réviser le code pour le modèle Singleton va un peu plus loin pour le rendre un peu plus clair, alors faisons cela maintenant:

 classe Foo / * -------------------------------------------- * * Les attributs *--------------------------------------------*/ / ** Fait référence à une seule instance de cette classe. * / private static $ instance = null; / * ------------------------------------------------ * * Constructeur * -------------------------------------------- * / / ** * Crée ou retourne une instance de cette classe. * * @return Foo Une seule instance de cette classe. * / fonction statique publique get_instance () if (null == self :: $ instance) self :: $ instance = new self;  return self :: $ instance;  // end get_instance; / ** * Initialise le plugin en définissant la localisation, les filtres et les fonctions d'administration. * / fonction privée __construct ()  // constructeur de fin / * ----------------------------------- ---------* * Les fonctions *------------------------------------- ------- * / // Fin de la classe Foo :: get_instance ();

De toute évidence, il y a eu beaucoup de code laissé en dehors de la classe ci-dessus, mais les principes du motif restent.

Notez que nous avons une variable d'instance statique privée utilisée pour faire référence à cette classe. Plus précisément, il est situé dans le get_instance fonction alors que le constructeur a été marqué comme privé.

Généralement, lors de l’instanciation de classes, le constructeur est la fonction appelée à chaque initialisation de classes; cependant, dans ce cas, le constructeur est marqué comme privé.

Alors qu'est-ce qui donne?

Notez que nous avons un public get_instance fonction juste au dessus du constructeur. Cette fonction vérifie littéralement si la variable d'instance statique est nul et, si tel est le cas, crée une nouvelle instance de la classe (ce qu'elle peut faire car elle se situe dans le contexte de la classe); sinon, il retourne l'instance actuelle.

C’est ainsi que pas plus d’une instance unique d’une classe est créée.

Enfin, notons que nous instancions la classe ne pas avec le standard Nouveau mot-clé, mais en appelant get_instance. Non seulement cela, mais nous obtenons également des références futures à la classe en utilisant la même méthode.

Ainsi, par exemple, disons que vous travaillez dans un autre modèle et que vous devez appeler une fonction - disons bar() - qui existe dans votre plugin. Dans ce cas, vous feriez quelque chose comme ceci:

 $ foo = Foo :: get_instance (); $ foo-> bar ();

Plutôt chouette, n'est-ce pas?

Les avantages du modèle Singleton

Bien que nous ayons traité du motif Singleton d’un point de vue architectural et pratique, nous n’avons pas encore parlé des avantages du motif..

En général:

Le modèle Singleton empêche d’autres objets ou clients de dupliquer des instances de la classe. Cela garantit qu’une seule copie des données est conservée à la fois. Tous les accès à l'objet sont effectués par l'instance unique.
Nous disposons d'une grande flexibilité en matière de mise en œuvre, car nous pouvons réellement influer sur le processus d'instanciation (bien que cela soit un peu hors de portée pour ce poste particulier)..

L’inconvénient majeur de l’utilisation du modèle est peut-être le manque de clarté sur le fait que le plugin utilise réellement le modèle. Si quelqu'un tente d'instancier la classe, l'instanciation échouera car il n'y a pas de constructeur public..

En tant que telle, la documentation est la clé.

Conclusion

Que vous les ayez vus auparavant ou qu'il s'agisse de votre première incursion dans les modèles de conception, le modèle Singleton est sans doute le modèle de conception le plus simple qui existe. Facile à mettre en œuvre, il constitue une source importante de fonctionnalités lorsqu'il est correctement implémenté, en particulier en ce qui concerne les applications Web..

Dans le prochain article, nous examinerons un autre modèle, le modèle d'usine simple, qui est utile lorsque vous avez plusieurs classes dont chacune a un objectif unique et qui seront nécessaires en fonction de certains critères d'entrée..

Code