Re: design problem with inheritance
On Aug 30, 12:20 am, Noah Roberts <roberts.n...@gmail.com> wrote:
On Aug 29, 3:50 am, James Kanze <james.ka...@gmail.com> wrote:
[...]
When I was mentioning a "static" version of the strategy pattern I was
specifically referring to "policy based design" where one cobbles
together a larger class out of "policy" classes that are basically
strategies within some concept.
This is more or less what I understood. Typically, the "policy"
class(es) will be traits, but you're correct that they don't
have to be; there are many ways to customize behavior, and
traits are just the most common (at least in the circles I
frequent).
No, they're not traits at all. A trait is something that provides
information about a type. Example: iterator_traits, provides category
information and other important tidbids for generic programming.
I've never heard that definition for traits before. The creator
of the concept (or at least the person who first described it,
and named it), seems to contradict himself in the definition: he
first says "it aggregates usefule types and constants", but then
says that "it provides an avenue for that 'extra level of
indirection' that solves all software problems", which suggests
more than just types and constants. (See
http://www.cantrip.org/traits.html.) And according to
Stroustrup (as quoted in
http://accu.org/index.php/journals/442), "Think of a trait as a
small object whose main purpose is to carry information used by
another object or algorithm to determine 'policy' or
'implementation details'."
In the standard, the most obvious example of a traits class is
char_traits, which is certainly a lot more than providing
information about a type: it tells std::basic_string how to do
certain operations. And the classical example of how a user
might exploit it is to make an instance of
std::basic_string<char> which is case insensitive. It's hard to
see how that differs from a policy.
A policy isn't like this at all and usually DOES have non-static
functions. Allocators are the nearest thing I can think of in the
standard library but that's still not quite correct.
Are you claiming that std::char_traits isn't a traits class.
Policy host classes generally inherit from their policies.
That makes for less typing when writing the class, but increases
coupling and makes the code less readable. Sounds like a poor
trade-off to me.
Wiki has a rather contrived
example:http://en.wikipedia.org/wiki/Policy-based_design
For a full and better description though grab a copy of
Alexandrescu's book.
Both policies and traits have been around long before
Alexandrescu wrote his book.
--
James Kanze