|
Boost : |
From: scleary_at_[hidden]
Date: 2001-11-14 11:48:03
> From: Gennadiy E. Rozental [mailto:rogeeff_at_[hidden]]
>
> --- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> > But if we move from technical to psychological reasons, many developers
> > think that a design pattern that has such a cool name absolutely needs
to
> > have an associated class (template.) The next trap they fall into, of
> > course, is in thinking that making a global variable a 'Singleton'
somehow
> > makes it less global and hence, acceptable. ;-)
>
> GoF defines Singleton as a pattern that ensures a class only has one
> instance and provide a global point of access to it. GoF does not
> elaborate the lifetime policy nor put any restriction on it.
That's because GoF is about *patterns*. Note how the GoF contrasts
frameworks and patterns: "Frameworks can be embodied in code, but only
_examles_ of patterns can be embodied in code. A strength of frameworks is
that they can be written down in programming languages... In contrast, the
design patterns in this book have to be implemented each time they're used."
The idea behind design patterns is that they are elements of reusable
software *design* (not code).
With the growing capability of template metaprograms/policy
classes/generative programming, this distinction can blur a bit. But I
think that the pains (in writing, using, and *especially* debugging both
library and user code) necessary to use such advanced constructs in C++ is
just not feasable. Personally, I like playing with them, and I would use
them on the implementation side of libraries, but I'm not ready to throw
them at an end user.
However, I do look forward to expressing (some) design patterns in a future
language. :)
-Steve
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk