2

Considering that Spring framework can manage pretty everything related to object creation (life cycle, object scope ..), is it longer necessary to use singleton pattern in an application using the framework, or are there still situations when we need to use Singleton pattern instead of singleton instance created by Spring?

One of the problem of using the singleton pattern is global state. Is the problem avoided using the Spring-defined singleton scope?

  • 2
    The problem of global state is overstated. The goal should be to have as little global state as possible, not to have no global state at all. In answer to your question, a singleton is a singleton. Spring just provides a convenient way to manage them. – Robert Harvey Jul 13 '16 at 16:26
1

"One of the problem of using the singleton pattern is global state"

If you use it for global state then you can do so. But that does not affect the "singleton pattern" itself as it is answering the question how many instances of an object there may be: One.

"global" and "state" do not adress the question "How many instances may be there?". They adress the questions "What is the scope?" and "May data change?" (mutability).

Spring will manage singletons for you. But the scope and mutability is up to you to define.

1

The problem with static singletons is not the global state per se. The problem is that they are usually used for shady things - one of the most common examples is a database connection.

Static singletons are wrong for one main reason: you can get an instance of a class the singleton wraps anywhere in the application, in any class, without ever letting a user of some class know the dependency actually exists.

Obviously, you can just to the same even when you don't have a static singleton and are somehow following dependency injection, by constructing a dependency in place (instead of passing it). But usually when you do that you realize much sooner that something is not right (even more so when the constructed dependency follows the dependency injection strictly and you are suddenly seeing not one, but like 7 new calls to construct the object graph). Singleton gives off the vibe that it's in fact ok, while in some cases it is not.

With hidden dependencies it just so happens you run a function taking a string parameter in development mode (or as a part of your unit test suite). This function will suddenly call the production database because it internally uses the singleton. If the dependency was known beforehand (the dependency would be passed into the function), you'd probably ask yourself why does the function need a database in the first place and be more careful before calling it.

The thing with Spring is, it will not fix design issues. But it can make constructing a heavily decoupled design (where pretty much everything is being passed as a dependency) easier to construct by running its magic and wiring the classes together based on some rules.

If you retrieve service classes and modules from Spring (or any other class type for that matter), you no longer need to tinker with factories and carefully manage your instances.

To ensure a thing which should exist only once actually exists only once you configure the framework and you are set. And that is amazing. The obvious downside is that it's done somehow and for less experienced programmers who have little to no experience with IoC container the magic may be off-puting (see Curse of knowledge).

I am personally somewhere in between whether a complete IoC framework is a good or a bad thing. I like to have some container responsible for managing my classes and assuring their scopes, but I am not a big fan of doing all this configuration using some kind of a XML configurator. I prefer newing the classes myself, inserting the manually newed instances into a container of choice and then always using the container to retrieve them back.

The manual part goes only one way, into the container. If I have a class demanding a dependency, I will ask for it from the container, meaning I will have to set it there first.

  • Good explication, But I can't see the difference between dependency injection and Singleton for "dependencies hidden" problem, in both cases you will not pass dependencies to a constructor. – Omar ZRIDI Jul 19 '16 at 13:52
  • @OmarZRIDI When using dependency injection you must pass the dependencies. That's what the injection means. If you think you don't have to do that, you got the wrong concept of dependency injection. Does not matter whether it's a constructor, property or any other injection, you should be passing dependencies no matter what. An object shouldn't be responsible for creating its dependencies, it should recieve them. – Andy Jul 19 '16 at 15:55
  • Spring nowadays can be configured completely in code, without a single line of XML. But also because Spring is not only a DI container but a full IoC container, simply newing manually would make many of the features harder or impossible (like transactions for example). – jhyot Aug 13 '16 at 8:43
1

The traditional definition of a Singleton means ensuring that only one instance of the singleton class ever exists, and providing global access to that instance.

This is not ideal because a) global state means that dependencies to the singleton can be unclear, and b) you cannot create a second version e.g. for testing.

Both problems are solved if you don't follow the traditional singleton pattern but just use Spring to make sure that there's only one object of the given class and inject it where it's needed (i.e. making the dependency explicit).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.