Reification of policy abstractions

I've been considering recently how I use 'policies as objects' in an implementation. I'm not quite sure where I got the notion from that this was good practice, but it does seem to work acceptably and allows for a degree of 'pluggability' - maybe it's just a take on the GOF Strategy idea. There is certainly some anthropomorphic  appeal; you may have had recourse to use a phrase like 'it is our policy to...' in relation to an action that was necessary based on certain conditions. A necessary action based on conditions, is classifiable (with a degree of artistic license!) as behaviour based on state. And with a Booch mindset in place, therefore has a direct relationship to object oriented practice.

So the interface definition below is a simple example I have to hand. An instance of a DCS provider manager (it does not matter awfully what that means) has an injected reference to an implementer of IDCSProviderManagerPolicy. At certain strategic points in it's behaviour, it can ask the policy for 'advice' on what to do when certain conditions are encountered. In the case of this example, whether recovery is possible when an error is encountered, and if there is a 'provider switch' available when an operation fails. All in all, a very simple abstraction indeed. My current project has two policy implementations; a 'fail always' policy, and an 'alternate providers once only' policy. Each is used for particular scenarios.

   /// <summary>  
   /// A reification of policy  
   /// </summary>  
   public interface IDCSProviderManagerPolicy {  
     /// <summary>  
     /// Returns true if the implementer adjudges it   
     /// possible that recovery may be attempted  
     /// </summary>  
     bool MayAttemptRecovery { get; }  
     /// <summary>  
     /// Invoked when a DCS provider operation fails  
     /// </summary>  
     IDCSProvider OperationFailed(IDCSProviderManager manager);  
   }