Supposons que vous ayez un système de l'autre côté d'un réseau qui envoie des événements et des données qui doivent être mis en cache dans un courtier intermédiaire. Au lieu de donner à chaque composant de votre application qui a besoin d'être informé de tels événements un nouvel abonnement au courtier, je décide de la performance et de la simplicité (la bibliothèque tierce qui gère les abonnements aux courtiers n'est pas jolie). Processeur d'événement qui s'abonne au courtier et déclenche par programmation les événements tels qu'ils les reçoivent aux écouteurs souscrits fournis par les composants. Les données mises en cache peuvent également être partagées à partir de ce singleton. Cela réduira considérablement les connexions réseau. Cependant, selon la plupart des discussions sur les singletons, ils sont toujours de mauvaises périodes, sauf si, pour des raisons de simultanéité ou pour des raisons matérielles, vous n'avez besoin que d'un seul point d'accès. Ce n'est pas ma situation puisque chaque composant pourrait avoir son propre abonnement et son propre cache personnel de données puisque toutes les données peuvent être demandées sur le courtier. Cependant, cela pourrait facilement ajouter 200 connexions réseau supplémentaires.Les processeurs d'événements réseau singleton sont-ils acceptables?
Parce que les singletons sont mal, cela signifie-t-il 200 connexions de plus à un courtier avec 200 copies de données est mieux que l'utilisation de singleton que je n'ai pas besoin d'utiliser? Après tout, cela ralentit un peu les choses, mais ce n'est pas un jeu, l'application est toujours utilisable.