Injectable Singleton - Revision history

JaroslavTulach at 06:52, 28 June 2023

JaroslavTulach — Wed, 28 Jun 2023 06:52:49 GMT

←Older revision		Revision as of 06:52, 28 June 2023
Line 89:		Line 89:
	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]]!
-
-	~~<comments/>~~


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

JaroslavTulach at 06:46, 28 June 2023

JaroslavTulach — Wed, 28 Jun 2023 06:46:20 GMT

←Older revision		Revision as of 06:46, 28 June 2023
Line 1:		Line 1:
-	[[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 ==

JaroslavTulach at 06:45, 28 June 2023

JaroslavTulach — Wed, 28 Jun 2023 06:45:19 GMT

←Older revision		Revision as of 06:45, 28 June 2023
Line 1:		Line 1:
-	[[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 ==

JaroslavTulach: /* Testability */

JaroslavTulach — Tue, 12 Oct 2021 07:25:05 GMT

Testability

←Older revision		Revision as of 07:25, 12 October 2021
Line 67:		Line 67:
	== [[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"/>

JaroslavTulach: /* Usage */

JaroslavTulach — Tue, 12 Oct 2021 07:22:57 GMT

Usage

←Older revision		Revision as of 07:22, 12 October 2021
Line 37:		Line 37:
	<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">

JaroslavTulach: /* Polemic */

JaroslavTulach — Tue, 09 Feb 2010 20:01:23 GMT

Polemic

←Older revision		Revision as of 20:01, 9 February 2010
Line 97:		Line 97:


-	[[Category:APIDesignPatterns]] [[APIDesignPatterns:Creational]] [[APIDesignPatterns:Meta]]	+	[[Category:APIDesignPatterns]] [[Category:APIDesignPatterns:Creational]] [[Category:APIDesignPatterns:Meta]]

JaroslavTulach at 19:58, 9 February 2010

JaroslavTulach — Tue, 09 Feb 2010 19:58:16 GMT

(Difference between revisions)

JaroslavTulach: /* Configure */

JaroslavTulach — Tue, 09 Feb 2010 19:31:13 GMT

Configure

←Older revision		Revision as of 19:31, 9 February 2010
Line 54:		Line 54:

	<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>

JaroslavTulach: /* Configure */

JaroslavTulach — Tue, 09 Feb 2010 19:30:39 GMT

Configure

←Older revision		Revision as of 19:30, 9 February 2010
Line 47:		Line 47:
	== 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">

JaroslavTulach: /* Defining the Singleton */

JaroslavTulach — Tue, 09 Feb 2010 19:26:46 GMT

Defining the Singleton

←Older revision		Revision as of 19:26, 9 February 2010
Line 21:		Line 21:
	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"/>