DEV Community

Effective Java Tuesday! Singletons!

Kyle Carter on October 01, 2019

Time for chapter three of our Effective Java review. Today's is a fairly simple one. Today we are talking about the singleton pattern. The singleto...

Read full post

jboschmans • Aug 4 '20

I know I'm late to the party, but I wonder why you would ever use the Singleton pattern instead of just a static class. Doesn't it achieve exactly the same?

Kyle Carter • Aug 4 '20

I'm not sure I'm following what you mean by "static class." The only static classes come to mind are static inner classes (dev.to/kylec32/effective-java-favo...) which don't solve the singleton problem but instead allows access to a nested class without having a handle on the outer class. Still useful, just not for this problem. Maybe I'm just misunderstanding the question thought.

jboschmans • Aug 4 '20

Thank you for your response. I guess I didn't explain very well. What I mean is a class where the members and methods are static. This way you can call the static method of the class to do what you want instead of creating an object. eg: ClassName.staticMethod()

Kyle Carter • Aug 5 '20

Thanks for that clarification. Yeah I don't see any problem with that. It seems like just a slight change from option 1. Potentially the downside I see is you don't keep the option of changing how it gets initialized in the future. If that's not needed then you likely are good with this option.

jboschmans • Aug 5 '20

Thank you for your answer!

Anton Rybochkin • Oct 2 '19

What about storing the singleton value in a static nested class?

Kyle Carter • Oct 3 '19

Interesting. I see no reason that you couldn't do that if it made sense to put the singleton in such a nested class. Something to keep in mind if the option ever comes up.

Anton Rybochkin • Oct 3 '19

I thought that was the official way to create lazy singletons without synchronization.

public class CEO {
  private CEO() { }

  public static CEO getInstance() {
    return InstanceHolder.instance;
  }

  public void fire(Employee slacker) { ... }

  private static final class InstanceHolder {
    private static final CEO instance = new CEO();
  }
}

Kyle Carter • Oct 4 '19

Will you look at that! Still never seen that but you are 100% correct this would allow lazy initialization without synchronization. Thanks for educating me about that.

Raghavan alias Saravanan Muthu • Jan 14 '21

Wow.. this is pretty awesome series. Gonna bookmark all the posts in this thread/series and start grasping them gradually. Thank you Kyle.

Ross Holloway • Nov 6 '19

"They are extremely hard to test" - why?

Kyle Carter • Nov 7 '19 • Edited

A fair question indeed, and one that I did not demonstrate above in my examples. Since the constructor is not accessible to us, even in a test, we are unable to change how the object is created and can't get the benefit of dependency injection (dev.to/kylec32/effective-java-tues...). While none of the above examples show any places where that would be a problem, many singletons in the wild do have this problem if they have any external dependencies (DB, network, other components, etc). So the more I think of it, it's likely the lack of ability to use dependency injection that is the true problem here.

Compare that to a singleton that is just a collection of pure functions that would indeed be testable (but at that point you are more looking at a Utility class dev.to/kylec32/effective-java-tues...)

Ross Holloway • Nov 7 '19 • Edited

I think you're right about Dependency Injection for unit testing with only, say, JUnit 5.

However, this is where I have found mocking libraries such as Mockito benefit the tests, as the coupled logic can be stubbed out.

(Thanks for the detailed reply 👍 )

Edit: Your second link doesn't appear to be working?

Himanshu Joshi • Oct 30 '19

Per Effective Java - we get the serialization machinery free.