Definition
Policy patterns refer to defining a series of algorithms and encapsulating them one by one. Separating the changeable part from the changeable part is the theme of every design pattern, and the strategy pattern is no exception. The purpose of the strategy pattern is to separate the use of the algorithm from the implementation of the algorithm.
Usually a policy-based program consists of at least two parts. The first part is a group of policy classes, which encapsulates specific algorithms and is responsible for the specific calculation process. The second part is the environment class Context, which accepts the customer's request and then delegates the request to a policy class.
Advantage:
- The strategy pattern can effectively avoid multiple conditional selection statements by utilizing technologies and ideas such as combination, delegation and polymorphism.
- The policy pattern provides perfect support for the open-close principle. It encapsulates the algorithms in a separate strategy, making them easy to switch, understand and expand.
- Combination and delegation are used in policy mode to enable Context to execute algorithms, which is also a lighter alternative to inheritance.
Example
Here's an example: Calculating the year-end award according to the performance level, the person with performance as S has four times the salary, the person with performance as A has three times the salary, and the person with performance as B has two times the salary.
java version
// The following are strategies. var performanceS =function(){}; performanceS.prototype.calculate = function( salary ) { return salary * 4; } var performanceA = function(){}; performanceA.prototype.calculate = function( salary ) { return salary * 3; } var performanceB = function(){}; performanceB.prototype.calculate = function( salary ) { return salary * 2; } // Here is the context. var Bonus = function(){ this.salary = null; // Initial wage this.strategy = null; // Strategic Objects Corresponding to Performance Level }; Bonus.prototype.setSalary = function( salary ) { this.salary = salary; // Setting up the original salary of employees } Bonus.prototype.setStrategy = function( strategy ) { this.strategy = strategy; } Bonus.prototype.getBonus = function() { return this.strategy.calculate( this.salary ); // Delegate the operation of calculating bonus to the corresponding strategic object } // Here are some examples var bonus = new Bonus(); bonus.setSalary( 10000 ); bonus.setStrategy( new performanceS() ); // Setting policy objects console.log( bonus.getBonus() ); // Output: 40000 bonus.setStrategy( new performanceA() ); // Setting policy objects console.log( bonus.getBonus() ); // Output: 30000
JavaScript Edition
Policy classes are often replaced by functions in the JavaScript language's policy pattern, which becomes an "invisible" pattern.
// The following are strategies. var strategies = { "S": function( salary ){ return salary * 4; }, "A": function( salary ){ return salary * 3; }, "B": function( salary ){ return salary * 2; } }; // Here's the context that hasn't changed, as above var Bonus = function(){ this.salary = null; // Initial wage this.strategy = null; // Strategic Objects Corresponding to Performance Level }; Bonus.prototype.setSalary = function( salary ) { this.salary = salary; // Setting up the original salary of employees } Bonus.prototype.setStrategy = function( strategy ) { this.strategy = strategy; } Bonus.prototype.getBonus = function() { return this.strategy.calculate( this.salary ); // Delegate the operation of calculating bonus to the corresponding strategic object } // Here are some examples var calculateBonus = function( level, salary ){ return strategies[ level ]( salary ); }; console.log(calculateBonus('S', 20000)); // Output: 80000 console.log(calculateBonus('A', 10000)); // Output: 30000
See if the above code feels comfortable. The second (js) is more comfortable than the first (java).
Remember: The policy pattern is that the delegation environment (only one) invokes different policies (multiple, and even-level)