The main content is about some notes and experiences when learning the design model.
Reference books available
Head first design patterns
Design Patterns: Elements of reusable object-oriented software
Implementation patterns.
The definitions of policy patterns in the two design patterns are the same: defining some column algorithms, encapsulating each algorithm, and making them interchangeable internally. The policy mode allows algorithms to change independently of users.
Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
As can be seen from the definition of policy patterns, because they can exchange internally, these algorithms must be common. Therefore, the first thing that comes to mind is that the classes that implement these algorithms inherit from the same parent class, of course, the same interface may be implemented in Java. If this kind of internal swapping is transparent to users, you must call the base class interface to send messages to the instance.
The following example describes how to use the rule pattern in head first design patterns.
First, define the context in the participant. In this example, the class duck is used. As a more important feature of context, you can define an interface to allow the policy class to access its internal data, this feature is not reflected in this example. The sample code in design patterns later contains this feature.
/** * Context class * - is configured with a ConcreteStrategy object * - maintains a reference to a Strategy object. * - may define an interface that lets Strategy access its data. * @author <Head First Design Pattern> */public abstract class Duck { // References to Strategy objects. protected FlyBehavior flyBehavior; protected QuackBehavior quackBehavior; public Duck() { } public abstract void display(); public void performFly() { flyBehavior.fly(); } public void performQuack() { quackBehavior.quack(); } // Interfaces for changing behaviors dynamically. public void setFlyBehavior(FlyBehavior fb) { flyBehavior = fb; } public void setQuackBehaviro(QuackBehavior qb) { quackBehavior = qb; } public void swim() { System.out.println("All ducks float, even decoys!"); }}
The policy class is defined as an interface class. The duck class can use the common methods defined in this interface class to call the algorithms in the instance class.
public interface FlyBehavior { public void fly();}
public interface QuackBehavior { public void quack();}
If the policy mode is implemented through the C ++ template class method class, you are not allowed to define abstract interfaces.
Next, you can define specific policies that meet the requirements of the policy interface.
public class FlyNoWay implements FlyBehavior { public void fly() { System.out.println("I can't fly"); }}
public class FlyRocketPowered implements FlyBehavior { public void fly() { System.out.println("I'm flying with a rocket!"); }}
public class FlyWidthWings implements FlyBehavior { public void fly() { System.out.println("I'm flying !!"); }}
public class MuteQuack implements QuackBehavior { public void quack() { System.out.println("<< Silence >>"); }}
public class Quack implements QuackBehavior { public void quack() { System.out.println("Quack"); }}
public class Squeak implements QuackBehavior { public void quack() { System.out.println("Squeak"); }}
According to the definition, policy design focuses on policies, that is, algorithms and policies can be dynamically changed independently from clients.
Therefore, in order to use the design pattern, the following context classes are not mandatory. Only one context exists.
public class MallardDuck extends Duck { public MallardDuck() { quackBehavior = new Quack(); flyBehavior = new FlyWidthWings(); } public void display() { System.out.println("I'm a real Mallard duck"); }}
public class ModelDuck extends Duck { public ModelDuck() { flyBehavior = new FlyNoWay(); quackBehavior = new Quack(); } public void display() { System.out.println("I'm a model duck"); }}
The client class is mainly responsible for controlling the combination of strategy and client.
public class MiniDuckSimulator { public static void main(String[] args) { Duck mallard = new MallardDuck(); mallard.performQuack(); mallard.performFly(); Duck model = new ModelDuck(); model.performFly(); model.setFlyBehavior(new FlyRocketPowered()); model.performFly(); }}
This example shows how to use the policy mode. However, in actual development, the policy class inevitably needs to access the data of the client class,
Therefore, it is sometimes important to interact between the client class and the strategy class in a low-coupling manner.
Two ideas are provided in the gof design model.
One approach is to have context pass data in parameters to strategy operations -- in other words, take the data to the strategy.
This keeps strategy and context decoupled. On the other hand, context might pass data the strategy doesn't need.
Another technique has a context pass itself as an argument, and the Strategy requests data from the context explicitly.
Of course, the best way is to depend on the data requirements associated with specific algorithms.
The application of policy mode includes the editor, code optimization, and financial devices.