Messagerie large application ... sans singletons?

Question

Donc, je veux aller pour un design plus sans singleton dans le futur. Cependant, il semble y avoir beaucoup de tâches dans une application qui ne peut pas être faite de manière significative sans singletons. Je les appelle les "services étendus à l'application", mais ils entrent également dans la même catégorie que les problèmes transversaux, que je corrige habituellement via AOP.

Prenons un exemple:

Je veux une application large file d'attente de messages qui envoie des messages aux composants, chaque composant peut souscrire et y publier, il est une très belle chose multicast. La file d'attente de messages et le système de répartition sont généralement une classe singleton (plutôt courte), ce qui est très facile à implémenter, disons, en C#. Vous pouvez même utiliser la double distribution et utiliser des métadonnées de type message et autres, tout est si facile à faire, c'est presque trivial. Cependant, avoir des singletons n'est pas vraiment une «conception orientée objet» (il introduit des variables globales) et cela rend les tests plus difficiles.

Avez-vous des idées? Je pose cette question parce que je suis disposé à apprendre plus sur ce sujet, beaucoup plus. :-)

Edit:

Je vous remercie tous pour vos réponses à ce jour. Je suppose que j'ai posé la mauvaise question, peut-être que cela aurait dû être "les singletons sont-ils vraiment si mauvais?". Il est un peu déroutant ... les gens vous disent "omg singletons bad smellz !! 11" partout - et d'autre part, ils semblent être la solution la plus simple et la plus simple à ces applications - problèmes de portée .

Ceci est l'un de mes "points de blocage" pour le moment. Résoudre cette énigme.

Answer 1

Si vous parlez de singletons de la manière que votre code d'application ne:

MessagingClass.getInstance().doStuff() 

dans vos méthodes, une alternative est d'utiliser « l'injection de dépendance ». Ce qui signifie que vous utilisez la même MessagingClass, mais que vous la fournissez aux classes qui l'utilisent via un constructeur ou un setter lors de leur création.

De cette façon, vous pouvez fournir différents types de MessagingClass dans différentes situations.

Notez que n'avez pas besoin d'un cadre d'injection de dépendance sur tout ce qui lui appartient.Edit: le point crucial de l'injection de dépendances est que votre code ne va pas chercher les classes dont il a besoin pour fonctionner (dépendances), il les "injecte" à la création. De cette façon, l'obtention de dépendances n'est pas mélangée avec le reste de votre code, ce qui semble être très utile.

Answer 2

Il est plus facile de comprendre le fonctionnement d'un logiciel lorsque le cycle de vie de tous les services/classes d'application est géré de manière centralisée. J'aime l'idée du JNDI.

Dans votre cas, j'aurais une instance de gestionnaire de files d'attente d'application disponible JNDI ou un service analogue. Le gestionnaire serait initialisé à la première demande du fournisseur de configuration disponible via le même mécanisme.

En général, lorsque vous avez besoin d'architecturer un système multiniveau d'entreprise, le J2EE est un bon endroit pour vérifier ce qui a déjà été inventé et utilisé.