Discussion :

[Lutarez]

Bonjour à tous,

Je suis confronté aujourd'hui à une situation que je rencontre finalement beaucoup, et je me pose une question en terme de design applicatif.
Ce n'est pas un vrai problème, juste une curiosité en matière de design, et j'aimerai avoir quelques avis concernant ce sujet.

Admettons que nous ayons plusieurs objets qui sont typiquement des singletons (appelons-les A, B et C).

Quel est le meilleur design pour gérer ces singletons :

• on accède à ces singletons de façon indépendante (via du A.Instance, B.Instance et C.Instance) ?
• on créé un singleton général (appelons-le D), qui regroupe tous les singletons de l'application (on obtient donc D.Instance.A, D.Instance.B, D.Instance.C) ?
  En partant de ce principe, A, B et C ne sont plus des singletons, mais D est responsable des instances uniques.

Votre avis m'intéresse

[Nathanael Marchand]

Bonjour à tous,

Je suis confronté aujourd'hui à une situation que je rencontre finalement beaucoup, et je me pose une question en terme de design applicatif.
Ce n'est pas un vrai problème, juste une curiosité en matière de design, et j'aimerai avoir quelques avis concernant ce sujet.

Admettons que nous ayons plusieurs objets qui sont typiquement des singletons (appelons-les A, B et C).



Quel est le meilleur design pour gérer ces singletons :

• on accède à ces singletons de façon indépendante (via du A.Instance, B.Instance et C.Instance) ?
• on créé un singleton général (appelons-le D), qui regroupe tous les singletons de l'application (on obtient donc D.Instance.A, D.Instance.B, D.Instance.C) ?
  En partant de ce principe, A, B et C ne sont plus des singletons, mais D est responsable des instances uniques.

Votre avis m'intéresse

Je préfère que chaque classe soit responsable de son instanciation. Surtout que si tu laisses D instancier A, B ou C, tu casses le pattern en rendant les constructeurs de celles-ci non privés

[sevyc64]

Une première réponse à apporter, avant même de se poser la question spécifiquement pour les singletons, et c'est dans le principe même de la programmation objet :

- Si tes objets ont un lien entre-eux tel que l'on peut les considérer comme étant des éléments d'un objet plus global, alors oui, on peut réfléchir à créer cet objet global pour y intégrer ces objets là qui y deviendront alors des éléments
- Si tes objets n'ont aucun lien entre-eux, qui ne correspondent pas à des entités similaires, alors non, on n'envisage même pas de les regrouper dans une entité de niveau supérieur.
Comme on dit, on ne mélange pas les chèvres et les choux.

Pour en revenir au singleton, j'ai rarement eu l'occasion d'en avoir à utiliser plusieurs dans un même projet, et j'ai même rarement eu l'occasion d'en avoir à utiliser régulièrement dans plusieurs projets. En fait les rares fois ou je ressent le besoin d'utiliser un singleton (une classe dans ces cas-là) sont à plus de 80% (estimatif) pour gérer la configuration du logiciel et la rendre disponible entre plusieurs modules, écrans, ...

[Lutarez]

Merci pour vos retours

Je préfère que chaque classe soit responsable de son instanciation. Surtout que si tu laisses D instancier A, B ou C, tu casses le pattern en rendant les constructeurs de celles-ci non privés

En .Net, on peut contourner le problème comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
A a = (A)Activator.CreateInstance( typeof(A), true );

Tu peux ainsi déclarer le constructeur de A en privé. Mais je suis absolument d'accord que cela casse en quelque sorte le pattern.

Une première réponse à apporter, avant même de se poser la question spécifiquement pour les singletons, et c'est dans le principe même de la programmation objet :

- Si tes objets ont un lien entre-eux tel que l'on peut les considérer comme étant des éléments d'un objet plus global, alors oui, on peut réfléchir à créer cet objet global pour y intégrer ces objets là qui y deviendront alors des éléments
- Si tes objets n'ont aucun lien entre-eux, qui ne correspondent pas à des entités similaires, alors non, on n'envisage même pas de les regrouper dans une entité de niveau supérieur.
Comme on dit, on ne mélange pas les chèvres et les choux.

C'est une remarque très juste. J'avoue ne pas y avoir penser...

Pour en revenir au singleton, j'ai rarement eu l'occasion d'en avoir à utiliser plusieurs dans un même projet, et j'ai même rarement eu l'occasion d'en avoir à utiliser régulièrement dans plusieurs projets. En fait les rares fois ou je ressent le besoin d'utiliser un singleton (une classe dans ces cas-là) sont à plus de 80% (estimatif) pour gérer la configuration du logiciel et la rendre disponible entre plusieurs modules, écrans, ...

Travaillant énormément sur des applications graphiques (WPF en ce moment), le besoin de communication entre plusieurs écrans est flagrant. C'est d'autant plus vrai, je trouve, en WPF avec les bindings.
En ce qui concerne le fait d'avoir plusieurs singletons, je dirai que cela dépend des besoins.

Par exemple, je travaille ces derniers temps sur un éditeur de code. J'utilise au sein de l'application trois singletons :

• un pour la configuration générale (langues, thèmes, gestion d'exception globales, etc);
• un autre singleton responsable de la gestion des fichiers (lecture, écriture, suppression, création);
• un dernier pour la compilation.

Les deux derniers pourraient très bien être instanciés de façon ponctuelle, lorsque le besoin se fait sentir. Sauf que j'ai besoin d'y avoir accès quelque soit l'écran, et ce avec d'éventuels passages d'arguments (par exemple, demander une compilation depuis le gestionnaire de fichier).

En pratique, cela fonctionne très bien, mais au fond, j'ai l'impression de commettre une énormité en terme de design.

[NicoL__]

Bonjour,
Juste une petite remarque, je pense qu'en .Net le problème c'est qu'il n'y a pas trop la culture de l'utilisation d'un framework IoC pour instancier et combiner les objet (Castle Windsor, Unity, Ninject).
C'est a ce genre de framework que l'on délègue l'instanciation des objets avec une stratégie pour chacun : singleton, pool, prototype...
Cela résoudrait tous ces questions.
Et pour info la classe D serait une factory basée sur des singletons, un design pattern assez reconnu, ça se fait bien... après faut-il mutiliplier les factory par classe et bien là ça dépend effectivement du contexte.
Sinon j'ai souvent remarqué qu'on code très rarement un singleton, c'est simple mais pas trivial... du coup il est souvent mal codé.

[Nathanael Marchand]

Sinon j'ai souvent remarqué qu'on code très rarement un singleton, c'est simple mais pas trivial... du coup il est souvent mal codé.

En même temps, le meilleur moyen de faire un singleton propre et thread safe maintenant, c'est d'utiliser Lazy<T>