Est-il mauvais d'utiliser des singletons pour des classes immuables sans argument?

Dans vos circonstances, l'utilisation du modèle Singleton a du sens. Pour une application simple, vous pouvez utiliser une méthode statique pour renvoyer l'instance. Si vous travaillez dans un environnement qui fournit une inversion de contrôle, tel que Spring, le framework IOC gérera les singletons pour vous.

Dans le cas où vous exposez des méthodes qui modifient l'état de la classe immuable, vous devez toujours renvoyer une nouvelle instance de cette classe.

Considérons les avantages et les inconvénients de singleton en supposant que vous avez un petit projet et des classes immuables qui sont utilisées comme valeurs de retour par défaut.

Avantages du singleton dans ce cas:

• L'application construit un objet au lieu de plusieurs ; Gardez à l'esprit que la construction d'un nouvel objet est généralement une opération bon marché en Java. Si vos objets ne vivent pas longtemps, GC les collectera sans impact significatif sur les performances de votre application. Cela s'applique si vous n'avez pas à créer des milliers de ces objets par seconde.

Inconvénients :

• Plus de code à lire et à écrire ; Bien que l'écriture des méthodes getInstance () puisse ne pas sembler un gros problème, d'autres personnes (potentiellement) travaillant avec vous passeront du temps à explorer ce que fait réellement getInstance () lors de la correction de bogues ou simplement comprendre une logique métier. J'ai vu un certain nombre de méthodes getInstance () surprenantes bien qu'elles aient un nom conventionnel.

• Problèmes potentiels de concurrence d'accès ; Même si votre projet est petit, vous souhaiterez peut-être utiliser plusieurs threads. Dans ce cas, vous devez écrire getInstance () comme méthode synchronisée, introduisez verrouillage revérifié , utilisez des énumérations ou autre chose. Même si vous êtes conscient de cette particularité, il n'est pas garanti que les autres développeurs ne feront pas d'erreur.

Il n'y a donc pas de bonne réponse, je pense, cela dépend de la façon dont vous voyez l'évolution de votre projet à l'avenir.

Même dans un petit projet, je m'efforcerais de respecter le Principe d'inversion de dépendance , c'est-à-dire qu'une classe n'instancie pas ses propres dépendances, mais les déclare, généralement dans un constructeur. De cette façon, chaque classe peut être développée et testée de manière isolée, tout en étant liée à tout le reste en utilisant soit un framework comme Spring ou Guice ou injection manuelle de dépendances . Avec une telle configuration, vous n'aurez probablement qu'une seule instance de la classe en question, mais vous n'aurez pas besoin d'implémenter un modèle de singleton classique.

Créer un petit projet consiste à faire les bons compromis: vous ne voulez pas sur-concevoir, mais vous ne voulez pas non plus écrire du code qui ne soit ni extensible ni maintenable. Donc non, il n'y a presque jamais d'excuse valable pour utiliser le modèle singleton (avec le chargeur de classe gardant le singleton).