Recipe23.4.Applying the Policy Design Pattern

Recipe 23.4. Applying the Policy Design Pattern

Problem

You want to define a set of development rules within a policy that can be applied to your application's structure.

Solution

Apply the Policy aspect-oriented design pattern. Figure 23-4 shows the key components of the Policy pattern.

Figure 23-4. The structure of the Policy pattern

The key roles in the Policy pattern shown in Figure 23-4 are:

ProjectPolicyAspect: The aspect that specifies project-wide or top-level policies for your application. This can optionally be declared abstract if it is to be extended by specialized subaspects.
ProjectSubAreaPolicyAspect: In this case, the ProjectPolicyAspect has been declared abstract leaving an abstract pointcut that gives this subaspect the ability to override the top-level rules according to the specifics of a particular project subarea's policy.

Discussion

The Policy pattern can declare a set of rules for any area within your application. Those rules can vary from being compiler errors and warnings to overriding the use of certain classes and libraries.

Example 23-5 is modified from Recipe 22.1 and shows how the Policy pattern can be implemented in AspectJ to specify a top-level policy for an example application that contains one rule stating that if the Java System.out.println(..) method is called then a warning is to be issued at compilation time.

Example 23-5. An example of the policy pattern being applying top level rules to an application

public abstract aspect ProjectPolicyAspect  {    protected abstract pointcut allowedSystemOuts( );        declare warning :         call(* *.println(..)) &&         !allowedSystemOuts( ) &&         !BorderControllerAspect.withinTestingRegion( )     : "System.out usage detected. Suggest using logging?"; }

Because, in this example, the top-level policy aspect is abstract and declares an abstract pointcut that can be used to override the System.out.println(..) rule, it can then be specialized for different areas within the target application, as shown in Example 23-6.

Example 23-6. Extending an abstract top-level policy

public aspect MyAppPolicyAspect extends ProjectPolicyAspect {    /**     * Specifies regions within the application where messages     * to System.out are allowed.     */    protected pointcut allowedSystemOuts( ) :        BorderControllerAspect.withinMyAppMainMethod( ) ||        BorderControllerAspect.withinThirdParty( ) ||        BorderControllerAspect.withinTestingRegion( ); }

Here are the key characteristics of the Policy pattern:

Provides a mechanism for rules that can be applied a compilation and runtime
Can be used to declare a hierarchy of complex rules for different areas of your application

The Policy pattern is useful in the following circumstances:

When you are developing an application where many developers are involved, such as in an open source project, and you want to convey some rules and guidelines for development more actively than simply by providing documentation.
The policies can be changed to facilitate migration of the application from one set of libraries and APIs to another. At first, the use of a set of libraries could be warned against in the policy; this could be increased to an error when the libraries must not be used. Finally, if the libraries are still being used for any reason, a proxy could be applied to move code away from the forbidden library to the policy preferred one.

The Policy pattern can collaborate with the following design patterns:

It may use the Cuckoo's Egg design pattern to override the usage of a particular class or library.
It may use the Proxy object-oriented design pattern to intercept calls to a particular class or library and either reject or delegate those calls to the right library or class according to the applications policy.

You may want to define specialized policies for different areas of your application building on the Border Controller design pattern.

Recipe23.4.Applying the Policy Design Pattern