Policy-based design
|
|
Policy-based design is a programming technique summarized as a compile-time equivalent of the Strategy pattern. Andrei Alexandrescu popularized this technique with his book Modern C++ Design (Addison-Wesley, 2001, ISBN 0201704315) and his column Generic<Programming> in the C/C++ Users Journal.
Overview
The technique is used to create a flexible set of types, providing the same interface, but employing different implementation behind. Therefore this technique has a lot of similarity to the Strategy pattern. However while Strategy allows the type to "change its ways" runtime, policy-based design fixes the implementation during compilation. In fact, it creates a new type for each different implementation. While their interface (functions present, their names etc.) will be the same, they will be different type - as opposed to Strategy, where the same type behaves differently.
The main idea is to use commonality-variability analysis to divide the type into the fixed implementation and interface (the policy based class) and the different policies. The main class, the policy based class takes template arguments (types, templates of types etc.) and delegates parts of the work to the policies.
The trick is to know what goes into the main class, and what policies should one create. Andrei's above mentioned excellent article gives us the clue: wherever we would need to make a possible limiting design decision, we should postpone that decision, we should delegate it to an appropriately named policy.
Policy classes can contain implementation, type definitions and so forth. Basically you, the designer of the main template class will define what the policy classes should provide, what customization points they need to implement.
As we go by the analysis in policy based design, it is a delicate task to create a good set of policies, just the right number. As little as necessary, but not less. The different customization points, which belong together, should go into one policy argument, such as StoragePolicy, ValidationPolicy and so forth. A good rule of thumb during design is that you should be able to give a name to your policy, which represents a concept, and not one which represent an operation or some really tiny implementation detail. PersistencePolicy seems to be a good choice, while HowToSavePolicy does not.
As you do your policy based design you will see how many other techniques will be useful, even if changed a bit, during your work. One example is that the Template Method pattern can be reinterpreted for compile time; so that your main class has a "skeleton" algorithm, which - at customization points - calls the appropriate functions of some the policies. You will also find yourself in using your policy classes as traits are used, asking type information, delegating type related tasks to it (a Storage policy is one example where it can happen).
External links
- Andrei Alexandrescu's Web site (http://www.moderncppdesign.com/)
- Generic<Programming>: A Policy-Based basic_string Implementation (http://moderncppdesign.com/publications/cuj-06-2001.html) by Andrei Alexandrescu