Beware singletons
From CSSEMediaWiki
(Difference between revisions)
RobertLechte (Talk | contribs) (New page: The Singleton design pattern has several apparent advantages. The programmer can be sure that only one instance will exist. That instance is static. This saves the mess of having to pa...) |
RobertLechte (Talk | contribs) |
||
| Line 1: | Line 1: | ||
| − | The [[Singleton]] design pattern has several apparent advantages. The programmer can be sure that only one instance will exist. That instance is static. This saves the mess of having to pass around many references to the object. Also, [[lazy | + | The [[Singleton]] design pattern has several apparent advantages. The programmer can be sure that only one instance will exist. That instance is static. This saves the mess of having to pass around many references to the object. Also, [[lazy initialisation]] is an inherent part of the pattern, which can improve performance. |
However, these advantages can tempt the programmer to make unwise design decisions. | However, these advantages can tempt the programmer to make unwise design decisions. | ||
* The assumption that only one instance will ever be required can be shortsighted. For example, one may have a settings object as a singleton. But if one later wishes to extend the software to run multiple objects each with their own settings, much painstaking refactoring will be required. | * The assumption that only one instance will ever be required can be shortsighted. For example, one may have a settings object as a singleton. But if one later wishes to extend the software to run multiple objects each with their own settings, much painstaking refactoring will be required. | ||
| − | * If you're using the static nature of the pattern to avoid passing around many references, it's a sign you might be overusing that class, and not following the maxim of [[Tell, don't ask]]. | + | * If you're using the static nature of the pattern to avoid passing around many references, it's a sign you might be overusing that class, and not following the maxim of [[Tell, don't ask]]. Possibly you have a [[God class]]. It's a sign that you should at least think about restructuring the code to reduce dependence on this class. |
| + | * You don't need a Singleton to make use of lazy initialisation. If you're using a Singleton just for this, then you definitely need to get rid of it. | ||
Revision as of 02:15, 5 October 2008
The Singleton design pattern has several apparent advantages. The programmer can be sure that only one instance will exist. That instance is static. This saves the mess of having to pass around many references to the object. Also, lazy initialisation is an inherent part of the pattern, which can improve performance.
However, these advantages can tempt the programmer to make unwise design decisions.
- The assumption that only one instance will ever be required can be shortsighted. For example, one may have a settings object as a singleton. But if one later wishes to extend the software to run multiple objects each with their own settings, much painstaking refactoring will be required.
- If you're using the static nature of the pattern to avoid passing around many references, it's a sign you might be overusing that class, and not following the maxim of Tell, don't ask. Possibly you have a God class. It's a sign that you should at least think about restructuring the code to reduce dependence on this class.
- You don't need a Singleton to make use of lazy initialisation. If you're using a Singleton just for this, then you definitely need to get rid of it.
