Injectable Singleton
From APIDesign
(→What this is not) |
|||
| Line 3: | Line 3: | ||
== What this is not == | == What this is not == | ||
| - | + | We are going to introduce an enhanced version of the [[singleton]] pattern that supports [[testability]], provides smooth [[Convention over Configuration]] and [[component injection]]. It can be seen as nice alternative companion to ''application context'' used by [[dependency injection]]. | |
| + | |||
| + | However when talking about [[singleton]] pattern, don't imagine [[Java]]'s '''SecurityManager''' or '''URLStreamHandlerFactory'''. Those are not [[Injectable Singleton]]s, they require non-trivial amount of initialization code and basically let your application knowledge leak out through out the system. | ||
== Configure == | == Configure == | ||
Revision as of 19:36, 27 January 2010
Singletons are sometimes dishonest as a design anti-pattern. Right, one may use them improperly, but with guidance of proper methodology there is nothing wrong on singletons. This page provides step by step cook book for usage of so called Injected Singletons.
Contents |
What this is not
We are going to introduce an enhanced version of the singleton pattern that supports testability, provides smooth Convention over Configuration and component injection. It can be seen as nice alternative companion to application context used by dependency injection.
However when talking about singleton pattern, don't imagine Java's SecurityManager or URLStreamHandlerFactory. Those are not Injectable Singletons, they require non-trivial amount of initialization code and basically let your application knowledge leak out through out the system.
Configure
TBD. Drop-in your implementations to classpath.
Testability
TBD. Use MockServices
- mention testing limitations due to levels of Co-existence and solutions
Injectable Meta-Singleton
- Lookup is meta!
Follow
