From: timatdvc (timw_at_[hidden])
Date: 2002-02-22 14:01:57
--- In boost_at_y..., Mat Marcus <mmarcus_at_A...> wrote:
[...]
> I see two main differences between C&E-style GenVoca and policy
> based design:
>
> Policy based design (PBD)
> * PBD uses Policies in two simultaneous roles, implemetation
> class templates and as a configuration DSL.
> * PBD favors policies which don't communicate; collaboration is
> orchestrated by a "manager" class template (e.g. SmartPtr)
>
> GenVoca
> * GenVoca uses layers (generalized policies) for the
> implementation class templates. A separate configuration
> generator is used to parse the configuration DSL
> * GenVoca offers (but does not require) the possiblity of
> communication between layers
>
> There is an appealing simplicity in PBD: no configuration generator
> is required. However, for some domains, the flexibility and
> reusabiity offered by GenVoca probably outweighs the cost of the
> additional required machinery. Of course, if you plan on writing a
> configuration generator anyway then I see no advantage to using
> policies instead of layers; in this case policies are merely the
> degenerate case of a zero-layered design.
[...]
What I am suggesting is that by combining a configuration generator
with PBD, the strenghts of each approach can be leveraged. The
simplicity of PBD makes it well-suited to implementing generic
libraries. The problem with PBD is that, as you pointed out, they
serve 2 roles (configuration and implementation). To use a policy-
based class or library, the user is responsible make low-level
choices in the solution domain. In a large library, the user
shouldn't be required to know the details of the smart pointer used
deep inside the library and how it should be configured. To make a
complex library (something with much coarser granularity than a smart
pointer, e.g., a generic database library) useable, low-level
policies should not be exposed to the end user.
Given a reasonable description of the likely uses of a domain
library, one could effectively come up with a mapping between domain
uses and the policies that best implement each possible use. This is
where a configuration generator would be perfect. There may not
necessarily be a one-to-one mapping from each configuration option to
a given policy. More likely, there would be a one-to-many
relationship, with some interdependencies between the options. A
generator could hide these details from the user by selecting the
appropriate policies for the provided options. Because the
configuration options would be in the language of the problem domain,
a user can make (fewer and easier) decisions closer to the problem
domain, thus making the library significantly easier to use.
One thing to keep in mind is that with either approach (PBD or
GenVoca), the generator interface could be exactly the same in either
case, so it really comes down to which method is easier to implement,
or provides the greatest benifit.
From my perspective and experience, which I'll admit is limited with
regard to GenVoca, PBD is one of the most straightforward and easily
learned techniques for *implementing* generic libraries where a
configuration generator makes *using* generic libraries easier. In
that respect, I think that combining them effictively can bring the
best of both worlds.