Informatique

je trouve ça extremement con de se passer des singletons pour certaines choses, pour moi c'est juste incontournable et j'en ai marre de voir des donneurs de leçons sur internet critiquer ce pattern ou semblables

je donne un exemple, je code une application graphique sur fenetre, au fin fond de mon code je veux connaitre la taille de la fenetre, peut-etre car je suis un component GUI et je veux etre proportionné correctement, ou bien peut etre que je suis une entité graphique qui bouge et je veux pas sortir de la fenetre .. bref très utile d'avoir accés à la taille.... donc faut accéder au coeur de notre moteur

avec singleton:

Engine::getInstance().getWindow().getSize()

sans singleton .. imaginons je suis un component d'un GUI:

this->getGuiManager().getState().getEngine().getWindow().getSize()

et ça peut etre encore plus long si vous etes dans des profondeurs abysmales de votre programme

Le pire c'est quand il y a aucun chemin d'accés, dans mon exemple du dessus heuresement j'ai le GuiManager qui me sert de chemin. Cela nous oblige à passer de classe en classe le pointeur du manager ou du state ou de je ne sais quoi .... bonjour les constructeurs degeulasses ou il faut toujours passer un argument , des references etc.

donc à part etre sado maschiste je vois aucun argument contre dans ce cas la d'utiliser un singleton, c'est pas comme si j'allais foutre plusieurs instance de mon Engine sur plusieurs threads ou je ne sais quoi

parce que c'est chiant pour les tests

donc à part etre sado maschiste je vois aucun argument contre dans ce cas la d'utiliser un singleton, c'est pas comme si j'allais foutre plusieurs instance de mon Engine sur plusieurs threads ou je ne sais quoi

Bah c'est ca le probleme fondamentallement. Quand tu fais un singleton et que tu l'utilise, tu forces l'objet a etre vraiment unique. Et si ca change dans le future, c'est le bordel. En fonction de l'utilisation c'est bien ou pas.
En general, meme si j'utilise un singleton, j'ai tendance a passer l'objet en parametre dans la plupart des cas pour eviter des problemes dans le future.

Un cas qui m'est arrive etait lie a un cache d'image un jeu. A priori c'est unique, mais en fait quand tu passes d'un niveau a l'autre, tu peux avoir besoin de garder les deux en vie pendant un temps. Tu veux virer le cache du niveau d'avant parceque tu ne vas pas tout reutiliser, mais tu veux garder les images qui vont reservir dans le niveau d'apres. Et donc temporairement il m'en falait deux.
Ca aurait pu etre ecrit fondamentalement differement pour ne pas avoir besoin de faire ca. Mais c'etait la solution la plus simple.

critiquer ce pattern

Ce n'est pas un pattern, bien au contraire. Sujet suivant.

@Le-Respect : il est présenté dans le Gangs of Four parmi les 24 autres pattern (et je n'aime pas ce type d'argument d'autorité en prime...). Idem, il est présenté dans les design pattern sur Wikipedia (et à peu près n'importe quelle autre source).
Si tu veux le remettre en question, libre à toi, mais étaye ;)

Puisque tu cites Wikipédia, lisons l'article, mais dans l'ordre :

un [design pattern] est un arrangement caractéristique de modules, reconnu comme bonne pratique en réponse à un problème de conception d'un logiciel.

Le singleton n'étant pas reconnu comme une bonne pratique, et posant souvent plus de problèmes de conception qu'il n'en règle, on peut conclure que ce n'est pas un pattern.

Un patron de conception est issu de l'expérience des concepteurs de logiciels [...]
[Ils] permettent en conséquence de capitaliser l'expérience appliquée à la conception de logiciel

L'expérience accumulée par les développeurs au cours des 24 dernières années n'est pas négligeable, depuis on a pigé des trucs et des gens ont écrit ce genre de choses :

• https://en.wikipedia.org/wiki/Singleton_pattern "There are some who are critical of the singleton pattern and consider it to be an anti-pattern in that it is frequently used in scenarios where it is not beneficial, introduces unnecessary restrictions in situations where a sole instance of a class is not actually required, and introduces global state into an application."
• https://www.linkedin.com/pulse/singleton-anti-pattern-manik-jain/
• https://www.michaelsafyan.com/tech/design/patterns/singleton
• https://dzone.com/articles/singleton-anti-pattern
• etc.

Et on ne peut pas nier des présentations aussi étayées que celles-ci avec juste des vieux trolls à base de "olololo c'est vraiment compliqué d'enchaîner 4 getters".
Si il ne veut pas faire de suite de getters, qu'il écrive des méthodes adaptées. Ou mieux, il n'a qu'à prendre en compte l'existence de l'encapsulation dans sa conception initiale. Quelle idée débile d'accéder à une propriété random depuis un endroit tout aussi random du code, ça ne ressemble à rien : soit il ne le fait pas et retourne à pôle emploi, soit il le fait avec une conception qui prend ce besoin en compte, soit il la ferme et il écrit ses 4 getters.

Le-respect,
le fait que le pattern est des fois mal utilise n'en fait pas un mauvais pattern. Un pattern s'utilise dans certaines situation. Si tu l'utilise pour masquer un abus de variable globale, c'est en effet completement debile et contre productif.
Mais dans des cas ou c'est precisement ce que tu veux, c'est un pattern utile.

Bawala ^^
C'est mieux
Merci.

Le 15 mars 2018 à 19:03:06 godrik a écrit :
Le-respect,
le fait que le pattern est des fois mal utilise n'en fait pas un mauvais pattern. Un pattern s'utilise dans certaines situation. Si tu l'utilise pour masquer un abus de variable globale, c'est en effet completement debile et contre productif.
Mais dans des cas ou c'est precisement ce que tu veux, c'est un pattern utile.

Tout est dit