From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-01-05 14:26:18
At 03:58 PM 1/4/2002, David Abrahams wrote:
>I have suggested several times that we look at the Policy Adaptor pattern
>used by the Iterator Adaptors Library. It certainly makes the problem of
>policy interaction go away, since all of the policies are collected in
one
>place... but there have been no replies, and I am wondering why. Is it
seen
>as inappropriate for smart pointers? Are people having trouble
>understanding the suggestion?
I am. Every time you mentioned it (once in person, several other times in
postings), I went back and read portions of the paper. In particular, the
section below. How does it a apply to smart pointers? Smart pointers
don't seem to have nice neat models of concepts like InputIterator,
ForwardIterator, BidirectionalIterator, or RandomAccessIterator. Or if
they did, there would be hundreds of them. I think the iterator example is
confusing me. With smart pointers the starting point (in my mind) is a
feature model. That translates nicely (as done by Andrei) into a set of
policies, which are for the most part orthongonal. Each of the policies
has two or more default implementations, corresponding to the common
feature variations for that Policy. I don't understand how to (usefully)
mash the policies together into a single policy. I'm basically lost.
--- start portion of the paper ---
The Policy Adaptor Design Pattern
The Iterator Adaptor Library illustrates how a generalized Model (iterator
adaptor) of a concept family (iterators) combined with default policy
delegation allows users to easily build new Models and behavioral adaptors
for existing Models. We can capture this strategy in the Policy Adaptor
design pattern: (see footnote below)
1. Identify the core elements of the public interface of the concept family
to be modeled. In our case, the Adaptor will model one of the iterator
concepts: InputIterator, ForwardIterator, BidirectionalIterator, or
RandomAccessIterator (this depends on the base iterator type and the
parameters of the Adaptor).
2. Encapsulate core elements of the concept family in a Policies concept.
3. Write a default policies class which delegates behavior to the public
interface of the Adaptor's concept. This is the mechanism that supplies
default adaptation behavior.
4. Build an Adaptor class template parameterized on Policies. The Adaptor
should be a generalized model of the Adaptor Concept, providing the public
interface, but delegating functionality to the policies class.
5. Store a member of the Policies parameter in the Adaptor template so that
users can maintain additional state while taking advantage of default
behavior delegation. We believe this design pattern is a powerful new tool
for modeling any concept which varies along several axes and contains
significant redundancy.
footnote: This is not quite the same as the Policy Class pattern which has
been discussed previously in the literature [Modern C++ Design]. The
construction of an adaptor which can easily transform existing Models into
new ones is the key difference
--- end portion of the paper ---