Also, the [[Injectable Singleton]]s as presented so far, are violating all the suggestions to [[Separate APIs for Clients and Providers]]. This may or may not matter. It is probably OK to use subclassable abstract classes for [[API]] that is from 99% called and only rarely implemented. This is often cause of [[singleton]]s - there is one instance and many callers. Thus violating the best practice may be acceptable (in [[NetBeans]] we have a lot of such [[singleton]]'s, ''WindowManager'', ''DialogDisplayer'', ''ExecutionEngine'' and we never faced much problems due to that - there are usually just three implementations of those - one default, one real, one for tests).

Also, the [[Injectable Singleton]]s as presented so far, are violating all the suggestions to [[Separate APIs for Clients and Providers]]. This may or may not matter. It is probably OK to use subclassable abstract classes for [[API]] that is from 99% called and only rarely implemented. This is often cause of [[singleton]]s - there is one instance and many callers. Thus violating the best practice may be acceptable (in [[NetBeans]] we have a lot of such [[singleton]]'s, ''WindowManager'', ''DialogDisplayer'', ''ExecutionEngine'' and we never faced much problems due to that - there are usually just three implementations of those - one default, one real, one for tests).

In case the dual nature of these [[Injectable Singleton]]s shall be a problem, the fix is simple. Just make all their methods ''protected abstract'' (as advocated in [[ClarityOfAccessModifiers]]). Then it will be clear that the [[singleton]] is here to be [[injection|injected]] and not called (no [[API]] client can call ''protected'' methods). Then, of course, you need to provide some other ''public'' methods that [[ClientAPI]] users can call. That is more verbose, but it clearly separates the concerns: There is a well defined [[API]] for clients as well as providers.

In case the dual nature of these [[Injectable Singleton]]s shall be a problem, the fix is simple. Just make all their methods ''protected abstract'' (as advocated in [[ClarityOfAccessModifiers]]). Then it will be clear that the [[singleton]] is here to be [[injection|injected]] and not called (no [[API]] client can call ''protected'' methods). Then, of course, you need to provide some other ''public'' methods that [[ClientAPI]] users can call. That is more verbose, but it clearly separates the concerns: There can be a well defined [[API]] for clients as well as providers.

Enjoy [[singleton]]s, make them [[Injectable Singleton|injectable]]!

Enjoy [[singleton]]s, make them [[Injectable Singleton|injectable]]!

[[Category:APIDesignPatterns]] [[Category:APIDesignPatterns:Creational]] [[Category:APIDesignPatterns:Meta]]

[[Category:APIDesignPatterns]] [[Category:APIDesignPatterns:Creational]] [[Category:APIDesignPatterns:Meta]]

[[Singleton]]s are sometimes dishonested as a design anti-pattern. True, one may use them improperly. But with guidance of proper methodology there is nothing wrong on [[singleton]]s. This page provides step by step cook book for usage of so called [[Injectable Singleton]]s.

[[Singleton]]s are sometimes dishonestly called a design anti-pattern. True, one may use them improperly. But with guidance of proper methodology there is nothing wrong on [[singleton]]s. This page provides step by step cook book for usage of so called [[Injectable Singleton]]s.

== What this is not ==

== What this is not ==

[[Singleton]]s are sometimes dishonest as a design anti-pattern. True, one may use them improperly. But with guidance of proper methodology there is nothing wrong on [[singleton]]s. This page provides step by step cook book for usage of so called [[Injectable Singleton]]s.

[[Singleton]]s are sometimes dishonested as a design anti-pattern. True, one may use them improperly. But with guidance of proper methodology there is nothing wrong on [[singleton]]s. This page provides step by step cook book for usage of so called [[Injectable Singleton]]s.

== What this is not ==

== What this is not ==

== [[Testability]] ==

== [[Testability]] ==

Of course, these days one just has to write code that is inherently testable. One of the critiques of [[singleton]] pattern was that it does not allow this. That it is not possible to ''mock'' in different [[singleton]] behavior during test execution. [[Injectable Singleton]]s are here to allow you to do exactly this:

Of course, these days one just has to write code that is inherently testable. Critics of regular [[singleton]] pattern accuse singletons from not being testable. That it is not possible to ''mock'' in different [[singleton]] behavior during test execution. [[Injectable Singleton]]s are here to allow you to do exactly this:

<source lang="java" snippet="singletons.injectable.test"/>

<source lang="java" snippet="singletons.injectable.test"/>

<source lang="java" snippet="singletons.injectable.usage"/>

<source lang="java" snippet="singletons.injectable.usage"/>

This makes the whole use as simple as possible by following the first half of the [[Convention over Configuration]] motto: ''If you are OK with default implementation, just use it''. As soon as a client code links with the [[API]] class, it can be sure that it will get reasonable implementation. No other configuration is needed. This is the output of such sample execution (which includes just the client code and the [singleton]]'s [[API]] with default implementation):

This makes the whole use as simple as possible by following the first half of the [[Convention over Configuration]] motto: ''If you are OK with default implementation, just use it''. As soon as a client code links with the [[API]] class, it can be sure that it will get reasonable implementation. No other configuration is needed. This is the output of such sample execution (which includes just the client code and the [[singleton]]'s [[API]] with default implementation):

<source lang="bash">

<source lang="bash">

[[Category:APIDesignPatterns]] [[APIDesignPatterns:Creational]] [[APIDesignPatterns:Meta]]

[[Category:APIDesignPatterns]] [[Category:APIDesignPatterns:Creational]] [[Category:APIDesignPatterns:Meta]]

<source lang="bash">

<source lang="bash">

$ java -jar DisplayerMain.jar -cp Displayer.jar:DefaultDisplayerImpl.jar

$ java -jar DisplayerMain.jar -cp Displayer.jar:SwingDisplayerImpl.jar

</source>

</source>

== Configure ==

== Configure ==

Of course, using the dummy implementation is not always optimal. As our systems get more and more [[Modularity|assembled at deploy time]] there especially needs to be a way to support easy configuration during application deployment. This is inherently supported due to adherence to [[ServiceLoader|Java Standard Extension Mechanism]]. Any time later, in any additional project that produces completely independent [[JAR]] file one can compile following piece of code:

Of course, using the dummy implementation is not always optimal. As our systems get more and more [[Modularity|assembled at deploy time]] there especially needs to be a way to support easy configuration during application deployment. This is inherently supported due to adherence to [[ServiceLoader|Java Standard Extension Mechanism]]. Any time later, while producing completely different [[JAR]] file, one can compile following piece of code:

<source lang="java" snippet="singletons.injectable.implement"/>

<source lang="java" snippet="singletons.injectable.implement"/>

The [[JAR]] containing this class (and the generated ''META-INF/services/'' entry, as generated by processing ''@ServiceProvider'' annotation via compile time [[AnnotationProcessor]] or alternatively created manually) can be put onto the application classpath. As soon as you do

The [[JAR]] containing this class (and the associated ''META-INF/services/'' entry, as generated by processing ''@ServiceProvider'' annotation via compile time [[AnnotationProcessor]] or alternatively created manually) can be put onto the application classpath. As soon as you do

<source lang="bash">

<source lang="bash">

In this case, the implementation of the '''yesOrNo''' method is really trivial and not very useful, but often there are cases when the default behavior can be made acceptable for many purposes.

In this case, the implementation of the '''yesOrNo''' method is really trivial and not very useful, but often there are cases when the default behavior can be made acceptable for many purposes.

Now the time as come to write proper initialization code (that will support [[Component Injection|extensibility]]). We can do it either in [[Java]]6 standard way via [[ServiceLoader]]:

Now the time has come to write proper initialization code (that will support [[Component Injection|extensibility]]). We can do it either in [[Java]]6 standard way via [[ServiceLoader]]:

<source lang="java" snippet="singletons.injectable.serviceloader"/>

<source lang="java" snippet="singletons.injectable.serviceloader"/>