"Domain-specific objects should be rich in the mechanism of the problem domain, but free from policy within that problem domain."

The above is paraphrased from 'C++ FAQs' (Cline & Lomow). (A version of this is online at http://www.cerfnet.com/~mpcline/On-Line-C++-FAQs/)

Rephrased into my own words: "Domain-specific objects should provide functionality in the problem domain without making assumptions as to how that functionality will be used."

MechanismRichPolicyFree is a fundamental design philosophy in the X Window System [XwindowProtocol], where it is called Mechanism Not Policy.  The Policy is intended to be provided by WindowManager''''''s and toolkits, such as KDE and Gnome.  

Some proponents of this principle tend to use the word policy (in this context) like a dirty word, almost suggesting that policy has no part anywhere in a system.

Others deride the X Window System for a perceived over-use or abuse of this principle (See the Unix-Hater's Handbook Chapter 7, which can be found on the world-wide web: http://www.art.net/~hopkins/Don/unix-haters/x-windows/disaster.html This is a mirror. I was unable to connect to the real home at http://web.kaleida.com/u/hopkins/unix-haters.html to verify the proper URL).

----

As you imply, the policy does have to live somewhere. Sometimes a wrapper can add value by enforcing a policy. In any case, the assumption of policy is hard to avoid - it tends to creep in by accident. When writing a class, you have an idea of how that class will be used - perhaps enshrined in UnitTest''''''s - which is an implicit policy. Sometimes you can make life easier for everyone by admitting it and avoiding the over-generalisation. -- DaveHarris

-------

I put this page here some time ago hoping I might find where it is that Policy lives in a system. I was looking in DesignPatterns the other day for a refresher on the StrategyPattern. It hit me like a ton of bricks when I read under Also''''''Known''''''As: Policy

This simple discovery has helped me in two ways. It validates the idea that policy is not to be eliminated, but contained. It has given me at least one pattern for encapsulating policy.
What a difference a name makes when you're as dense as I am. I'm like the proverbial mule. Sometimes you have to hit me upside the head with a 2 by 4 to get my attention... 

-- TimVoght

----

I believe we are looking at two different definitions of Policy: the DesignPatterns definition and the definition suggested by your quote.  DesignPatterns seems to suggest a flexible way to implement a Policy without naming the "intent" of a Policy.  The definition of Policy that you use, I believe, is the localization of object management that is likely to change.  

For example, the JavaSecurityManager and its associated policy files:  The Security''''''Manager can be subclassed to behave like a Strategy.  However it is a Policy because its behavior is both CrossCutting and easily changeable. 
 
----
See PrematureGeneralization, ContrivedInterfaces