5

I read so many bad things about singleton pattern (What is so bad about singletons?), however, @Singleton is used everywhere in this Micronaut doc to illustrate inversion of control https://docs.micronaut.io/1.3.0.M2/guide/index.html#ioc

When is it appropriate to use @Singleton? For example, if I have a UserInfoService that has getUserInfo, createUserInfo, updateUserInfo method, is it a good idea to use @Singleton?

Another separate question is when do I use @Prototype, because if I don't use any annotation for a function/class, isn't it by default a prototype (as in I initiate a new instance of it in another class/function)?

cgrim
  • 4,890
  • 1
  • 23
  • 42
user12300055
  • 53
  • 1
  • 3

3 Answers3

5

When is it appropriate to use @Singleton? For example, if I have a UserInfoService that has getUserInfo, createUserInfo, updateUserInfo method, is it a good idea to use @Singleton?

UserInfoService should almost certainly be a stateless singleton.

Another separate question is when do I use @Prototype, because if I don't use any annotation for a function/class, isn't it by default a prototype (as in I initiate a new instance of it in another class/function)?

If you initiate a new instance, then the annotation doesn't matter. The annotation only affects instances that the Micronaut container creates for you. For @Singleton the container creates a single instance and injects the same instance at all injection points that require it. For @Prototype the container creates a new instance for each injection point.

All of this is about application design more than it is about Micronaut. Micronaut provides a simple mechanism for you to declaratively express (by way of @Singleton or @Prototype) whether or not you want the same instance to be shared or not but the issue is really about application design. In general you should prefer stateless singletons. If for some reason you have a bean that must be stateful and you have good reasons to not want to share instances from different contexts, then @Prototype might be appropriate.

I hope that helps.

Jeff Scott Brown
  • 26,804
  • 2
  • 30
  • 47
1

Let's be 100% clear that the GoF Singleton design pattern and the @Singleton annotation are two different things.

Consider that the Singleton design pattern requires you to change your code. You must write the code in such a way as to prevent multiple instantiations.

On the other hand, you can add the @Singleton annotation to any class you like, without modifying its code to prevent instantiation; and as @Jeff-Scott-Brown points out, you can instantiate this Micronaut "Singleton" repeatedly by simply calling its constructor.

The @Singleton annotation does not exhibit those negative consequences you've read about in the Singleton design pattern, because it doesn't implement the Singleton design pattern. The term is overloaded to mean two different things here.

On a related note the @Prototype annotation doesn't follow the GoF Prototype design pattern either.
Spring prototype following prototype design pattern

jaco0646
  • 15,303
  • 7
  • 59
  • 83
-1

As Jeff Scott Brown covers most parts of your question, your have to be careful to the nuance between Singleton scope in Spring and singleton pattern.

Some of the main differences between these 2 are

  • Singleton pattern ensures one instance of a particular class of per class loader.
  • Spring Singleton is “per container per bean”.

Hope that helps.

Katy
  • 1,023
  • 7
  • 19
  • "...your have to be careful to the nuance between Singleton scope in Spring and singleton pattern." - That may be true but I don't think Spring is involved. – Jeff Scott Brown Feb 04 '22 at 14:00