Policy-based design is a programming technique, which one could call the compile-time equivalent of the Strategy pattern. The policy-based design I know has been introduced as a C++ template programming technique. It has received wide public attention with Andrei Alexandrescu's Generic<Programming>: A Policy-Based basic_string Implementation article in the expert sections of 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. (This makes policy-based design a real male programming technique, as it is all based on fear of commitment.)

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).

Further Reading

Please be sure to read Andrei's article mentioned in the introduction. You may want to read his further articles from Andrei.

You can also check the Once Weakly series of Steve Dewhurst at his web site. Contains many good articles along the lines of template programming, things you will need to know, if you want to do policy-based design.

If you like the idea of writing less code and more software, be sure to check out of reviews Andrei's bestseller book Modern C++ Design and if you find it promising go to Andrei's site and order it using the link.