Re: Single Object Instance Techniques
Phlip wrote:
JohnQ wrote:
Why would anyone write:
class SomeThing // class littered with non-domain single-instancing code
:(
{
private:
SomeThing();
static SomeThing* pInstance_;
I don't have the book Design Patterns to hand. Under Singleton, does it show
the above code, or this correct code below?
SomeThing* GetSomeThing() // single-instancing accessor function
{
static SomeThing* thing = new SomeThing();
return thing;
}
If you must Singleton, do it like that.
Aren't those two equivalent Philip? The only difference that I see is
that the pointer is directly class accessible and accessible to the
outside only via the function (which does the test on first use
explicitly, instead of implicitly by way of the static inside of the
function). Although, I guess that the compiler may be able to do some
optimisations using the implicit test? What do you think?
However, Singleton is a very abusable pattern when it enables rampant
coupling. The "instantiate once" motivation is not the same as the
"available to everyone like a big fat global" motivation. The latter is an
antipattern!
... 'SingleInstancer' should be a template class.
Such a template is often the result of a junior effort with Singleton. I
don't think it solves the problem how to prevent secondary instantiation of
the templated type.
Do you say this because of how some linkers may work? I think that most
(if not all) of the newer linkers are supposed to amalgamate all
statically linked multiple instances of the same templates. DLLs and
shared memory spaces are a different matter. It would require extra
care and would have to incorporate that into your design of your
application system.
Furtherless, if you have unit tests, you _need_ secondary instatiation, so
you can fake objects for your tests!
I don't agree. You can do unit tests on a singleton. In fact, your
domain is somewhat narrowed with a singleton as since there is only one
instance floating around, you don't have to worry about interactions
with others of the same type, and can optimise based on that pattern.
Singletons should be treated with high suspicion.
Singletons are just like most patterns. Design patterns are a way of
sharing insight on common problems and are useful. This limits but does
not eliminate the abuse of such patterns.
Adrian
--
_____________________________________________________________________
\/Adrian_Hawryluk BSc. - Specialties: UML, OOPD, Real-Time Systems\/
\ My newsgroup writings are licensed under the Creative Commons /
\ Attribution-Noncommercial-Share Alike 3.0 License /
\_____[http://creativecommons.org/licenses/by-nc-sa/3.0/]_____/
\/______[blog:__http://adrians-musings.blogspot.com/]______\/