2 votes

Allocation de mémoire, Singletons, et quand les utiliser/éviter.

Je suis tombé sur cette page qui présente un aperçu très complet des singletons.

Au lieu de l'habituel "Un Singleton est une classe avec un constructeur privé et une seule instance globale", il décrit un Singleton comme suit :

Il est important de définir exactement ce que nous entendons par "singleton".

Pour les besoins de cet argument, un singleton est tout état mutable qui est accessible sans partir de la pile (c'est-à-dire accessibles à partir de variables statiques ou globales).

Habituellement, un singleton est une classe dont l'auteur s'attend à ce qu'il n'y ait qu'une seule instance. Cependant, pour nos besoins, tout objet qui est globalement accessible compte.

Exemples :

  • Un ensemble de fonctions (ou de méthodes statiques) qui manipulent un état mutable partagé constitue un singleton.
  • Si un singleton A fournit une référence à un objet mutable B, alors B est également un singleton.
  • Cela implique que chaque membre mutable d'une collection singleton est lui-même un singleton.
  • Un objet transitivement immuable n'est PAS un singleton, même s'il est globalement accessible. C'est une constante.
  • Une fonction autonome qui n'accède à aucun singleton n'est PAS elle-même un singleton, en supposant que le code est immuable.

...

Qu'en est-il de open() ou de stdout ?

Ce sont là quelques-uns des pires exemples de singletons !
...

Cela signifie, essentiellement, que malloc , new , shared_ptr ou tout ce que votre langage utilise pour accéder à la mémoire du tas - tous ces éléments utilisent des singletons !

Pourtant, personne ne dit qu'il faut éviter l'allocation au tas pour cette raison. Allocation de mémoire semble être négligé partout ! Même sur la page que j'ai citée, ils mentionnent open() y stdout et la journalisation, mais ils ne mentionnent jamais l'allocation de la mémoire du tas - qui est clairement plus "dangereuse" que, disons, un enregistreur, parce que ce n'est pas une rue à sens unique.

Donc ma question est, l'allocation de mémoire est-elle une exception à la règle (pourquoi ?), ou bien est-elle également un mauvais exemple de singletons ?

Comment puis-je décider si une nouvelle utilisation des singletons entre dans cette même catégorie "exceptionnelle" ?

(étiqueté comme agnostique au niveau du langage pour des raisons évidentes, mais également étiqueté comme C++ car je pense qu'il est particulièrement pertinent pour C++ parce qu'il permet à l'utilisateur de modifier le comportement de <code>new</code> et introduire un état plus global).

1voto

Oli Charlesworth Points 148744

Par définition, votre programme n'interagit qu'avec un seul monde extérieur. Personne ne peut donc prétendre que ce n'est pas un exemple de singleton !

Mais du point de vue de la conception d'un logiciel, je dirais que "bien" ou "pas bien" n'est en fait qu'une question de "cela peut-il me poser des problèmes" et de "puis-je faire quelque chose à ce sujet".

Pour quelque chose comme la production, la réponse aux deux est "oui". Dans un programme complexe, il y a des avantages considérables (tests, injection de dépendances, etc.) obtenus en encapsulant la sortie dans des objets non squelettes. Pour quelque chose comme la mémoire système, pas vraiment.

Vous pouvez chercher à éliminer une partie du couplage inhérent (en effet, le système d'exploitation, le runtime du langage et des éléments tels que les allocateurs personnalisés le font tous dans une certaine mesure dans le cas de la mémoire). Il peut également être utile d'encapsuler toute votre allocation de mémoire derrière des objets, afin de permettre de tester la réponse d'une application complexe à des conditions hors mémoire. Mais vous ne pouvez toujours pas éliminer complètement le couplage global.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X