This page is my attempt to explain this [[paradox]]. It may not be complete yet and certainly needs correction. If you have one, feel free to [[Talk:Singleton|share it]]:

This page is my attempt to explain this [[paradox]]. It may not be complete yet and certainly needs correction. If you have one, feel free to [[Talk:Singleton|share it]]:

I started by reading the Miško's articles references by Witold. Let's thus use them as headers that will guide us though out this polemic.

I started by reading the Miško's articles references by Witold. Let's thus use them as headers that will guide us though out this polemic.

First of all it is easy to ''don't mix object construction and application logic''. Instead of constructing objects, one only calls the [[singleton]]'s getter and gets properly initialized instance of the requested interface. Thus one codes just the application logic, the object construction is handled behind the scene by the [[Lookup|infrastructure]].

First of all it is easy to ''don't mix object construction and application logic''. Instead of constructing objects, one only calls the [[singleton]]'s getter and gets properly initialized instance of the requested interface. Thus one codes just the application logic, the object construction is handled behind the scene by the [[Lookup|infrastructure]].

It is easy to ''rarely call new operation'' - one does not instantiate services, those are offered via various [[API]] singletons. Enough to get them. However, there is an important limitation: In the server terminology one would say that in such system, there is only one factory: the ''application factory''. There are no ''request factories''. The application factory is determined by the classes loaded into the system. All the classes linked together represent one factory (they can have many different [[singleton]]s, but they are all tight together into one configuration set). If I wanted to have different set of singleton values, I would need to load the classes by different classloader again (see [[co-existence]] for more details).

It is easy to ''rarely call new operation'' - one does not instantiate services, those are offered via various [[API]] singletons. Enough to get them. However, there is an important limitation: In the server terminology one would say that in such system, there is only one factory: the ''application factory''. There are no ''request factories''. The application factory is determined by the classes loaded into the system. All the classes linked together represent one factory (they can have many different [[singleton]]s, but they are all tight together into one configuration set). If I wanted to have different set of singleton values, I would need to load the classes by different [[ClassLoader]] again (see [[co-existence]] for more details).

The fact that the [[singleton]] approach supports just ''application factory'' shows the benefits of using true [[dependency injection]]. On the other hand the approach is not inherently limiting. For many applications (especially on desktop) it is fine to have just ''application factories''. There is only one ''help system'', one ''dialog presenter'', one VGA card[http://netbeans.org/projects/platform/lists/dev/archive/2010-01/message/406], etc. Thus this limitation does not violate any [[good]] design practices. Using [[singleton]]s in this way is completely fine.

The fact that the [[singleton]] approach supports just ''application factory'' shows the benefits of using true [[dependency injection]]. On the other hand the approach is not inherently limiting. For many applications (especially on desktop) it is fine to have just ''application factories''. There is only one ''help system'', one ''dialog presenter'', one VGA card[http://netbeans.org/projects/platform/lists/dev/archive/2010-01/message/406], etc. Thus this limitation does not violate any [[good]] design practices. Using [[singleton]]s in this way is completely fine.

Properly used [[Injectable Singleton|singleton]]s are not that bad as one might think after being massaged by [[dependency injection]] campaigns. As soon as we have [[singleton]]s that are inherently initialized and [[injection|injectable]], we get a solution which is on par with solutions provided by [[dependency injection]] (of course just with ''class level'' [[co-existence]], but that is an [[API]] decision, not an implementation flaw).

Properly used [[Injectable Singleton|singleton]]s are not that bad as one might think after being massaged by [[dependency injection]] campaigns. As soon as we have [[singleton]]s that are inherently initialized and [[injection|injectable]], we get a solution which is on par with solutions provided by [[dependency injection]] (of course just with ''class level'' [[co-existence]], but that is an [[API]] decision, not an implementation flaw).

Moreover we managed to increase [[cluelessness]] of our [[API]] users. Whenever one wants to start using an [[API]] with [[Injectable Singleton]]s, one does not need to spend time writing implementation of any interfaces or properly configure system to provide them. Trivial implementations are inherently present in the [[Injectable Singleton]]s by itself. Of course, if one is not satisfied by them, one is allowed to provide better ones. In some way the [[Injectable Singleton]]s bring the [[Component Injection]] much closer to the motto of [[Convention over Configuration]]: ''If you don't care, use the defaults. If that is not enough for you, specify an alternative''!

Moreover we managed to increase [[cluelessness]] of our [[API]] users. Whenever one wants to start using an [[API]] with [[Injectable Singleton]]s, one does not need to spend time writing implementation of any interfaces or properly configure system to provide them. Trivial implementations are inherently present in the [[Injectable Singleton]]s by their own. Of course, if one is not satisfied by them, one is allowed to provide better ones. In some way the [[Injectable Singleton]]s bring the [[Component Injection]] much closer to the motto of [[Convention over Configuration]]: ''If you don't care, use the defaults. If that is not enough for you, specify an alternative''!

With ten years of active use, seamless [[testability]] (via ''seams''), adherence to [[Convention over Configuration|simplicity of use]] and also with possible bridges with modern [[Dependency Injection]] technologies (see [[LookupAndSpring]]), I would not dare to call [[singleton]]s old trash. Try [[Injectable Singleton]]s, you'll find them friendly!

With ten years of active use, seamless [[testability]] (via ''seams''), adherence to [[Convention over Configuration|simplicity of use]] and also with possible bridges with modern [[Dependency Injection]] technologies (see [[LookupAndSpring]]), I would not dare to call [[singleton]]s old trash. Try [[Injectable Singleton]]s, you'll find them friendly!

[[Category:APIDesignPatterns]]

[[Category:APIDesignPatterns]]

Let's look how various Miško's advices about testability materialize when using proper [[singleton]]s.

Let's look how various Miško's advices about testability materialize when using proper [[singleton]]s.

The test shall be a ''small instance of the application''. How small it can be? As small as the tested part that links together. This means that you can have only only [[API]]s you compiled against on your classpath. Nothing else. And yes, this is satisfied (even to greater extent than any [[Dependency Injection|DI]] solution allows): As the [[API]]s offering [[Injectable Singleton]]s have to provide their default ''dummy'' implementation, you are fine to have just them on the execution classpath. Whatever you compiled against is enough to run reasonably well.

The test shall be a ''small instance of the application''. How small it can be? As small as the tested part that links together. This means that you can have only [[API]]s you compiled against on your classpath. Nothing else. And yes, this is satisfied (even to greater extent than any [[Dependency Injection|DI]] solution allows): As the [[API]]s offering [[Injectable Singleton]]s have to provide their default ''dummy'' implementation, you are fine to have just them on the execution classpath. Whatever you compiled against is enough to run reasonably well.

Of course, the default implementations may not be sufficient for testing all aspects of your application. Often you need to test different behavior than the [[singleton]] provides by itself. Here we need to have a ''seam'', a place to change the standard behavior in a testing handy way. But wait! We have a ''seam''! Each [[Injectable Singleton]] is in fact one!

Of course, the default implementations may not be sufficient for testing all aspects of your application. Often you need to test different behavior than the [[singleton]] provides by itself. Here we need to have a ''seam'', a place to change the standard behavior in a testing handy way. But wait! We have a ''seam''! Each [[Injectable Singleton]] is in fact one!

Let's look how various Miško's advices about testability materialize when using proper [[singleton]]s.

Let's look how various Miško's advices about testability materialize when using proper [[singleton]]s.

The test shall be a small instance of the application. How small it can be? As small as the tested part that links together. This means that you can have only only [[API]]s you compiled against on your classpath. Nothing else. And yes, this is satisfied (even to greater extent than any [[Dependency Injection|DI]] solution allows): As the [[API]]s offering [[Injectable Singleton]]s have to provide their default ''dummy'' implementation, you are fine to have just them on the execution classpath. Whatever you compiled against is enough to run reasonably well.

The test shall be a ''small instance of the application''. How small it can be? As small as the tested part that links together. This means that you can have only only [[API]]s you compiled against on your classpath. Nothing else. And yes, this is satisfied (even to greater extent than any [[Dependency Injection|DI]] solution allows): As the [[API]]s offering [[Injectable Singleton]]s have to provide their default ''dummy'' implementation, you are fine to have just them on the execution classpath. Whatever you compiled against is enough to run reasonably well.

Of course, the default implementations may not be sufficient for testing all aspects of your application. Often you need to test different behavior than the [[singleton]] provides by itself. Here we need to have a ''seam'', a place to change the standard behavior in a testing handy way. But wait! We have a ''seam''! Each [[Injectable Singleton]] is in fact one!

Of course, the default implementations may not be sufficient for testing all aspects of your application. Often you need to test different behavior than the [[singleton]] provides by itself. Here we need to have a ''seam'', a place to change the standard behavior in a testing handy way. But wait! We have a ''seam''! Each [[Injectable Singleton]] is in fact one!

Properly used [[Injectable Singleton|singleton]]s are not that bad as one might think after being massaged by [[dependency injection]] campaigns. As soon as we have [[singleton]]s that are inherently initialized and [[injection|injectable]], we get a solution which is on par with solutions provided by [[dependency injection]] (of course just with ''class level'' [[co-existence]], but that is an [[API]] decision, not an implementation flaw).

Properly used [[Injectable Singleton|singleton]]s are not that bad as one might think after being massaged by [[dependency injection]] campaigns. As soon as we have [[singleton]]s that are inherently initialized and [[injection|injectable]], we get a solution which is on par with solutions provided by [[dependency injection]] (of course just with ''class level'' [[co-existence]], but that is an [[API]] decision, not an implementation flaw).

Moreover we managed to increase [[cluelessness]] of our [[API]] users. Whenever one wants to start using an [[API]] with [[Injectable Singleton]]s, one does not need to spend time to write implementation of such interfaces or properly configure system to provide one. Trivial implementations are inherently present in the [[Injectable Singleton]]s by itself. Of course, if one is not satisfied by them, one is allowed to provide better ones. In some way the [[Injectable Singleton]]s bring the [[Component Injection]] much closer to the motto of [[Convention over Configuration]]: ''If you don't care, use the defaults. If that is not enough for you, specify an alternative''!

Moreover we managed to increase [[cluelessness]] of our [[API]] users. Whenever one wants to start using an [[API]] with [[Injectable Singleton]]s, one does not need to spend time writing implementation of any interfaces or properly configure system to provide them. Trivial implementations are inherently present in the [[Injectable Singleton]]s by itself. Of course, if one is not satisfied by them, one is allowed to provide better ones. In some way the [[Injectable Singleton]]s bring the [[Component Injection]] much closer to the motto of [[Convention over Configuration]]: ''If you don't care, use the defaults. If that is not enough for you, specify an alternative''!

With ten years of active use, seamless [[testability]] (via ''seams''), adherence to [[Convention over Configuration|simplicity of use]] and also with possible bridges with modern [[Dependency Injection]] technologies (see [[LookupAndSpring]]), I would not dare to call [[singleton]]s old trash. Try [[Injectable Singleton]]s, you'll find them friendly!

With ten years of active use, seamless [[testability]] (via ''seams''), adherence to [[Convention over Configuration|simplicity of use]] and also with possible bridges with modern [[Dependency Injection]] technologies (see [[LookupAndSpring]]), I would not dare to call [[singleton]]s old trash. Try [[Injectable Singleton]]s, you'll find them friendly!

[[Category:APIDesignPatterns]]

[[Category:APIDesignPatterns]]

Properly used [[Injectable Singleton|singleton]]s are not that bad as one might think after being massaged by [[dependency injection]] campaigns. As soon as we have [[singleton]]s that are inherently initialized and [[injection|injectable]], we get a solution which is on par with solutions provided by [[dependency injection]] (of course just with ''class level'' [[co-existence]], but that is an [[API]] decision, not an implementation flaw).

Properly used [[Injectable Singleton|singleton]]s are not that bad as one might think after being massaged by [[dependency injection]] campaigns. As soon as we have [[singleton]]s that are inherently initialized and [[injection|injectable]], we get a solution which is on par with solutions provided by [[dependency injection]] (of course just with ''class level'' [[co-existence]], but that is an [[API]] decision, not an implementation flaw).

Moreover we managed to increase [[cluelessness]] of our [[API]] users. Whenever one wants to start using an [[API]] with [[Injectable Singleton]]s, one does not need to spend time to write implementation of such interfaces or properly configure system to provide one. Trivial implementations are inherently present in the [[Injectable Singleton]]s by itself. Of course, if one is not satisfy with them, one is allowed to provide better ones. In some way the [[Injectable Singleton]]s bring the [[Component Injection]] much closer to the motto of [[Convention over Configuration]]: ''If you don't care, use the defaults. If that is not enough for you, specify an alternative''!

Moreover we managed to increase [[cluelessness]] of our [[API]] users. Whenever one wants to start using an [[API]] with [[Injectable Singleton]]s, one does not need to spend time to write implementation of such interfaces or properly configure system to provide one. Trivial implementations are inherently present in the [[Injectable Singleton]]s by itself. Of course, if one is not satisfied by them, one is allowed to provide better ones. In some way the [[Injectable Singleton]]s bring the [[Component Injection]] much closer to the motto of [[Convention over Configuration]]: ''If you don't care, use the defaults. If that is not enough for you, specify an alternative''!

With ten years of active use, seamless [[testability]] (via ''seams''), adherence to [[Convention over Configuration|simplicity of use]] and also with possible bridges with modern [[Dependency Injection]] technologies (see [[LookupAndSpring]]), I would not dare to call [[singleton]]s old trash. Try [[Injectable Singleton]]s, you'll find them friendly!

With ten years of active use, seamless [[testability]] (via ''seams''), adherence to [[Convention over Configuration|simplicity of use]] and also with possible bridges with modern [[Dependency Injection]] technologies (see [[LookupAndSpring]]), I would not dare to call [[singleton]]s old trash. Try [[Injectable Singleton]]s, you'll find them friendly!

[[Category:APIDesignPatterns]]

[[Category:APIDesignPatterns]]

Properly used [[Injectable Singleton|singleton]]s are not that bad as one might think after being massaged by [[dependency injection]] campaigns. As soon as we have [[singleton]]s that are inherently initialized and [[injection|injectable]], we get a solution which is on par with solutions provided by [[dependency injection]] (of course just with ''class level'' [[co-existence]], but that is an [[API]] decision, not an implementation flaw).

Properly used [[Injectable Singleton|singleton]]s are not that bad as one might think after being massaged by [[dependency injection]] campaigns. As soon as we have [[singleton]]s that are inherently initialized and [[injection|injectable]], we get a solution which is on par with solutions provided by [[dependency injection]] (of course just with ''class level'' [[co-existence]], but that is an [[API]] decision, not an implementation flaw).

Moreover we managed to increased our users [[cluelessness]]. Whenever one wants to start using an [[API]] with [[Injectable Singleton]]s, one does not need to spend time to write implementation of such interfaces or properly configure system to provide one. Trivial implementations are inherently present in the [[Injectable Singleton]]s by itself. Of course, if one is not satisfy with them, one is allowed to provide better ones. In some way the [[Injectable Singleton]]s bring the [[Component Injection]] much closer to the motto of [[Convention over Configuration]]: ''If you don't care, use the defaults. If that is not enough for you, specify an alternative''!

Moreover we managed to increase [[cluelessness]] of our [[API]] users. Whenever one wants to start using an [[API]] with [[Injectable Singleton]]s, one does not need to spend time to write implementation of such interfaces or properly configure system to provide one. Trivial implementations are inherently present in the [[Injectable Singleton]]s by itself. Of course, if one is not satisfy with them, one is allowed to provide better ones. In some way the [[Injectable Singleton]]s bring the [[Component Injection]] much closer to the motto of [[Convention over Configuration]]: ''If you don't care, use the defaults. If that is not enough for you, specify an alternative''!

With ten years of active use, seamless [[testability]] (via ''seams''), adherence to [[Convention over Configuration|simplicity of use]] and also with possible bridges with modern [[Dependency Injection]] technologies (see [[LookupAndSpring]]), I would not dare to call [[singleton]]s old trash. Try [[Injectable Singleton]]s, you'll find them friendly!

With ten years of active use, seamless [[testability]] (via ''seams''), adherence to [[Convention over Configuration|simplicity of use]] and also with possible bridges with modern [[Dependency Injection]] technologies (see [[LookupAndSpring]]), I would not dare to call [[singleton]]s old trash. Try [[Injectable Singleton]]s, you'll find them friendly!

[[Category:APIDesignPatterns]]

[[Category:APIDesignPatterns]]

In this piece Miško admits that using ''immutable [[singleton]]'' is OK. Good progress since the first write up. Now the question is what is meant by ''immutable''? The content of help system window is certainly not immutable and still it is fine to provide access to its [[API]] via a [[singleton]] under the assumption that it is ready to perform its operation (display some help page). Thus I am going to assume that ''immutable'' [[singleton]] means ''not configurable'' or without a need to call some init code to ''configure'' it. Let's see the necessary attributes of [[injectable singleton]]s to eliminate any need for ''configuration''.

In this piece Miško admits that using ''immutable [[singleton]]'' is OK. Good progress since the first write up. Now the question is what is meant by ''immutable''? The content of help system window is certainly not immutable and still it is fine to provide access to its [[API]] via a [[singleton]] under the assumption that it is ready to perform its operation (display some help page). Thus I am going to assume that ''immutable'' [[singleton]] means ''not configurable'' or without a need to call some init code to ''configure'' it. Let's see the necessary attributes of [[injectable singleton]]s to eliminate any need for ''configuration''.

First of all the [[API]] itself needs to provide some implementation of the [[singleton]]. This implementation may be trivial, yet have to be functional. For example a [[singleton]] that is supposed to show dialogs to user and ask questions may always print the question to System.err and choose ''cancel''. This way we eliminate the worry that [[singleton]]s may lie about their dependencies - they don't have any. As soon as the system successfully links, all [[singleton]]s are ready to work fine.

First of all the [[API]] itself needs to provide some implementation of the [[singleton]]. This implementation may be trivial, yet have to be functional. For example a [[singleton]] that is supposed to show dialogs to user and ask questions may always print the question to System.err and choose ''cancel''. This way we eliminate the worry that [[singleton]]s may lie about their dependencies - they don't have any. As soon as the system successfully links, all [[singleton]]s are ready to work.

Second, the implementations of the [[singleton]]s need to be [[injection|injectable]] - e.g. it is possible to [[injection|inject]] better implementation into the [[singleton]]. Such [[injection]] can happen only before the [[singleton]] is used and (preferably) without invoking any initialization code (see [[Injectable Singleton#Configuration|injectable configuration]] for details). This serves two important goals. Production systems are configured to provide ''clever'' (read not ''dummy'') implementations of the [[singleton]]s without affecting code using these [[singleton]]s. Also, it is possible to easily mock each [[singleton]] in a unit test fully addressing needs of [[Injectable Singleton#Testability|testability]].

Second, the implementations of the [[singleton]]s need to be [[injection|injectable]] - e.g. it is possible to [[injection|inject]] better implementation into the [[singleton]]. Such [[injection]] can happen only before the [[singleton]] is used and (preferably) without invoking any initialization code (see [[Injectable Singleton#Configuration|injectable configuration]] for details). This serves two important goals. Production systems are configured to provide ''clever'' (read not ''dummy'') implementations of the [[singleton]]s without affecting code using these [[singleton]]s. Also, it is possible to easily mock each [[singleton]] in a unit test fully addressing needs of [[Injectable Singleton#Testability|testability]].

In this piece Miško admits that using ''immutable [[singleton]]'' is OK. Good progress since the first write up. Now the question is what is meant by ''immutable''? The content of help system window is certainly not immutable and still it is fine to provide access to its [[API]] via a [[singleton]] under the assumption that it is ready to perform its operation (display some help page). Thus I am going to assume that ''immutable'' [[singleton]] means ''not configurable'' or without a need to call some init code to ''configure'' it. Let's see the necessary attributes of [[injectable singleton]]s to eliminate any need for ''configuration''.

In this piece Miško admits that using ''immutable [[singleton]]'' is OK. Good progress since the first write up. Now the question is what is meant by ''immutable''? The content of help system window is certainly not immutable and still it is fine to provide access to its [[API]] via a [[singleton]] under the assumption that it is ready to perform its operation (display some help page). Thus I am going to assume that ''immutable'' [[singleton]] means ''not configurable'' or without a need to call some init code to ''configure'' it. Let's see the necessary attributes of [[injectable singleton]]s to eliminate any need for ''configuration''.

First of all the [[API]] itself needs to provide some implementation of the [[singleton]]. This implementation may be trivial, yet have to be functional. For example a [[singleton]] that is supposed to show dialogs to user and ask questions may always print the question to System.err and choose ''cancel''. This way we eliminate the worry that [[singleton]]s may lie about their dependencies - they don't they have any. As soon as the system successfully links, all [[singleton]]s are ready to work fine.

First of all the [[API]] itself needs to provide some implementation of the [[singleton]]. This implementation may be trivial, yet have to be functional. For example a [[singleton]] that is supposed to show dialogs to user and ask questions may always print the question to System.err and choose ''cancel''. This way we eliminate the worry that [[singleton]]s may lie about their dependencies - they don't have any. As soon as the system successfully links, all [[singleton]]s are ready to work fine.

Second, the implementations of the [[singleton]]s need to be [[injection|injectable]] - e.g. it is possible to [[injection|inject]] better implementation into the [[singleton]]. Such [[injection]] can happen only before the [[singleton]] is used and (preferably) without invoking any initialization code (see [[Injectable Singleton#Configuration|injectable configuration]] for details). This serves two important goals. Production systems are configured to provide ''clever'' (read not ''dummy'') implementations of the [[singleton]]s without affecting code using these [[singleton]]s. Also, it is possible to easily mock each [[singleton]] in a unit test fully addressing needs of [[Injectable Singleton#Testability|testability]].

Second, the implementations of the [[singleton]]s need to be [[injection|injectable]] - e.g. it is possible to [[injection|inject]] better implementation into the [[singleton]]. Such [[injection]] can happen only before the [[singleton]] is used and (preferably) without invoking any initialization code (see [[Injectable Singleton#Configuration|injectable configuration]] for details). This serves two important goals. Production systems are configured to provide ''clever'' (read not ''dummy'') implementations of the [[singleton]]s without affecting code using these [[singleton]]s. Also, it is possible to easily mock each [[singleton]] in a unit test fully addressing needs of [[Injectable Singleton#Testability|testability]].