Unlimited WordPress themes, graphics, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Design Patterns
Code

Patrons de conception: Singleton

by
Difficulty:IntermediateLength:ShortLanguages:

French (Français) translation by Thomas Triboult (you can also view the original English article)

Dans cet article vous apprendrez à implémenter le patron Singleton ainsi que pourquoi et quand utiliser ce patron dans votre application. Comme le nom "Singleton" le suppose, cette méthode vous permet de créer une et une seul instance d'une classe.

Regardons ce que Wikipedia peut nous dire de ce patron :

Le singleton est un patron de conception dont l'objet est de restreindre l'instanciation d'une classe à un seul objet. Il est utilisé lorsque l'on a besoin d'exactement un objet pour coordonner des opérations dans un système.

Comme mentionné dans la définition ci-dessus, lorsque l'on veut être sûr qu'un et un seul objet doit être créé pour une classe, alors on doit implémenter le patron Singleton pour cette classe.

Vous pouvez vous demander pourquoi nous devons implémenter cette casse qui nous autorise l'instanciation d'un seul objet. Je vous répondrais qu'il y a beaucoup de cas d'utilisation où l'on peut appliquer ce patron de conception. Cela inclus : les classes de configuration, de session, de base de données et tant d'autres.

Je prendrais l'exemple d'une classe de base de données pour cet article. Premièrement nous verrons quel peut être le problème si le patron singleton n'est pas implémenté sur cette classe.

Le problème

Imaginez une classe de connexion à la base de données très simple qui créé une connexion avec la base de données lorsqu'on créé un objet de cette classe.

Dans le code ci-dessus, vous pouvez voir qu'on créé une connexion à la base de données à chaque fois que vous créez un objet de cette classe. Donc, si un développeur a créé un objet de cette classe à plusieurs endroits, imaginez le nombre de connexion (identiques) que cela créera avec le serveur de base de données.

Donc sans le savoir le développeur fait des erreurs qui auront un énorme impact sur la rapidité de la base de données et du serveur applicatif. Regardons la même chose en créant un objet différent de cette classe.

Si vous regardez la sortie du code ci-dessus, vous verrez que chaque objet à sa propre resource ID, donc tous les objets sont des références différentes, et par conséquent une allocation mémoire séparée est faite pour chaque connexion. Inconsciemment votre application va consommer de ressources dont elle n'a pas vraiment besoin.

La solution

Nous ne controlons pas comment les développeurs utilisent notre framework. Nous le contrôlons après la procédure de revue de code, mais pendant le développement nous ne pouvons pas les surveiller tout le temps.

Pour palier ce problème, nous devons rendre notre classe de base instanciable qu'une seul fois ; elle retournera l'instance créé si elle existe déjà. C'est le cas d'utilisation pour lequel nous avons décidé d'implémenter le patron Singleton pour nos classes de base.

En développant ce patron, nous nous concentrons sur le fait qu'il autorise la création d'un objet d'une classe une et une seule fois. Laissez moi vous montrer le code de cette classe et ensuite nous le détaillerons.

Il y a quelques indications sur le fait que cette classe soit un Singleton. La première, un constructeur privé qui empêche l'instanciation via le mot clé new. Mais aussi un attribut statique qui contient la référence vers un objet déjà créé.

Si on compare la sortie des deux sections de code précédentes on voit, dans la sortie du patron Singleton, que la resource ID de l'objet est la même pour tous les objets. Mais ce n'est pas le cas lorsque l'on utilise pas le patron.

Singleton comme anti-patron

Ce patron de conception est aussi appelé un anti-patron pour plusieurs raisons que je vais détailler ci-dessous :

  1. Ces une violation du SRP car il maîtrise sa propre création et son cycle de vie.
  2. Cela ajoute un état global à votre application. Je dirais que l'état global est mauvais car n'importe quel code peut changer sa valeur. Lors du débogage il devient difficile de trouver quelle partie du code à modifié l'état de la variable globale.
  3. Singleton est souvent un mauvais patron lorsque vous utilisez les tests unitaires et c'est une mauvaise idée que de ne pas faire de tests unitaires.

Conclusion

J'ai fait mon possible pour expliquer le patron de conception Singleton qui est largement abordé sur internet. J'espère que vous aurez trouvé cet article utile. Nous avons abordé les deux aspects de ce patron qui sont en tant que patron et en tant qu'anti-patron.

Posez vos questions, commentaires et/ou suggestions ci-dessous et je vous répondrais le plus rapidement possible. Vous pouvez aussi me contacter sur Twitter @XpertDevelopers ou par email.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.