Learning JavaScript design patterns (Rule patterns) _ javascript tips-js tutorial

This article mainly guides you through the JavaScript design model, which focuses on the Rule mode, analyzes the rule mode with the year-end award as an example, and analyzes the rule mode in detail, if you are interested, please refer to what is the strategy? For example, if we want to travel somewhere, we can select a route based on the actual situation.
1. Policy mode definition

If you don't have time but don't care about money, you can choose to fly.
If you have no money, you can choose to take a bus or train.
If you are a little poorer, you can choose to ride a bicycle.
In program design, we often encounter similar situations. There are multiple options to implement a function. For example, you can select the zip algorithm or gzip Algorithm for a compressed file program.

Definition:Policy mode defines a series of algorithms, which are encapsulated separately so that they can be replaced with each other. This mode allows algorithm changes to be independent of customers who use computation.

Rule modes are widely used. This section describes how to calculate the year-end bonus.

2. year-end bonus instance

The year-end awards of many companies are based on the salary base of employees and the performance at the end of the year. For example, A person with A performance of S has A salary of 4 times, A person with A performance of A has A salary of 3 times, and A person with A performance of B has A salary of 2 times. Suppose the finance department asks us to provide a piece of code to help them calculate the employee's year-end bonus.

1). Initial code implementation

We can write a function named calculateBonus to calculate the bonus amount of each person. Obviously, if the calculateBonus function needs to work correctly, two parameters must be received: the employee's salary and his/her performance evaluation level. The Code is as follows:

Var calculateBonus = function (performanceLevel, salary) {if (performanceLevel = 's') {return salary * 4;} if (performanceLevel = 'A ') {return salary * 3;} if (performanceLevel = 'B') {return salary * 2 ;}}; calculateBonus ('B', 20000); // output: 40000 calculateBonus ('s ', 6000); // output: 24000

It can be found that this code is very simple, but there are obvious shortcomings.

CalculateBonus functions are relatively large,Contains many if-else statements that must overwrite all logical branches.

The calculateBonus function lacks flexibility,If a new performance level C is added, or you want to change the reward factor of performance S to 5, you must go deep into the internal implementation of the calculateBonus function, which violates the open-closed principle.

The reusability of algorithms is poor. What if we need to reuse these algorithms in other places of the program? We only select copy and paste. Therefore, we need to refactor this code.

2). Use composite functions to reconstruct the code

Generally, the easiest way to think of is to use composite functions to reconstruct it. we encapsulate various algorithms into small functions. These small functions are well named, you can clearly know which algorithm it corresponds to, and they can also be reused elsewhere in the program. The Code is as follows:

Var performanceS = function (salary) {return salary * 4 ;}; var performanceA = function (salary) {return salary * 3 ;}; var performanceB = function (salary) {return salary * 2;}; var calculateBonus = function (performanceLevel, salary) {if (performanceLevel = 's') {return performanceS (salary );} if (performanceLevel = 'A') {return performanceA (salary);} if (performanceLevel = 'B') {return performanceB (salary );}}; calculateBonus ('A', 10000); // output: 30000

At present, our program has been improved, but this improvement is very limited, we still have not solved the most important problem: the calculateBonus function may become larger and larger, in addition, there is a lack of flexibility when the system changes.

3). Use the policy mode to reconstruct the code

After thinking, we have come up with a better solution-using the policy pattern to refactor the code. Policy mode refers to defining a series of algorithms and encapsulating them one by one. Separating the unchanged and changing parts is the topic of each design pattern, and the policy pattern is no exception. The purpose of the policy pattern is to separate the use of the algorithm from the implementation of the algorithm.

In this example, the algorithm usage remains unchanged, and the calculated bonus amount is obtained based on an algorithm. The implementation of algorithms varies and changes, and each performance corresponds to different computing rules.

A policy-based program consists of at least two parts. The first part is a set of policies that encapsulate specific algorithms and are responsible for specific computing processes. The second part is the environment Context. The Context accepts the customer's request and then delegates the request to a certain strategy class. To do this, it means that the reference to a policy object must be maintained in Context.

Now we use the policy mode to refactor the above Code. The first version imitates the implementation in the traditional object-oriented language. First, we encapsulate the computing rules of each type of performance in the corresponding policy class:

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;};

Next we will define the Bonus class Bonus:

Var Bonus = function () {this. salary = null; // original salary this. strategy = null; // policy object corresponding to the performance level}; Bonus. prototype. setSalary = function (salary) {this. salary = salary; // set the employee's original salary}; Bonus. prototype. setStrategy = function (strategy) {this. strategy = strategy; // set the policy object corresponding to the employee performance level}; Bonus. prototype. getBonus = function () {// get the bonus amount return this. strategy. calculate (this. salary); // delegate the calculation bonus operation to the corresponding policy object };

Before completing the final code, let's review the ideas of the Policy Model:

Define a series of algorithms, encapsulate them one by one, and make them replace each other.

To be more detailed, we define a series of algorithms and encapsulate them into a strategy class. The algorithms are encapsulated in the internal methods of the strategy class. When a customer initiates a request to Context, Context always delegates the request to one of these policy objects for calculation.

"And make them replace each other", which is largely relative to static type languages. Because there is a type check mechanism in the static type language, each policy class needs to implement the same interface. They can be replaced only when their real types are hidden behind the interface. This is not a problem in the "type fuzzy" language of JavaScript, and any object can be replaced and used. Therefore, "can be replaced with each other" in JavaScript shows that they have the same purpose and intent.

Now let's complete the remaining code in this example. Create a bonus object and set raw data for the bonus object, such as the employee's original salary. Next, we will pass a bonus calculation policy object to the bonus object for internal storage. When bonus. getBonus () is called to calculate the bonus, the bonus object itself does not have the ability to calculate, but delegates the request to the previously saved policy object:

Var bonus = new Bonus (); bonus. setSalary (1, 10000); bonus. setStrategy (new CES (); // sets the console of the Policy object. log (bonus. getBonus (); // output: 40000 bonus. setStrategy (new performanceA (); // sets the console of the Policy object. log (bonus. getBonus (); // output: 30000

We have just reconstructed the computing year-end award code using the policy model. We can see that after restructuring the policy model, the Code becomes clearer and the responsibilities of each class become clearer. However, this Code is based on the traditional object-oriented language. In the next section, we will understand the rule Mode Implemented with JavaScript.

In section 5.1, we create a strategy object from each policy class, simulating the implementation of some traditional object-oriented languages. In fact, in JavaScript, functions are also objects. Therefore, the simpler and more direct method is to define strategy as a function:

var strategies = { "S": function( salary ){ return salary * 4; }, "A": function( salary ){ return salary * 3; }, "B": function( salary ){ return salary * 2; }}; 

Similarly, Context does not need to be expressed using the Bonus class. We still use the calculateBonus function as the Context to accept user requests. After transformation, the code structure becomes more concise:

Var strategies = {"S": function (salary) {return salary * 4 ;}, "A": function (salary) {return salary * 3 ;}, "B ": function (salary) {return salary * 2 ;}}; var calculateBonus = function (level, salary) {return strategies [level] (salary) ;}; console. log (calculateBonus ('s ', 20000); // output: 80000console. log (calculateBonus ('A', 10000); // output: 30000

3. Explain the instance

A small example will show us at a glance.
Recall the animate method in jquery.

$ (P ). animate ({"left: 200px"}, 1000, 'linear '); // constant motion $ (p ). animate ({"left: 200px"}, 1000, 'cubic '); // cubic easing

These two codes allow p to move 200 pixels to the right within Ms. linear (uniform speed) and cubic (cubic power easing) are encapsulation of a policy mode.

Another example is that many pages have a form for instant verification. Each member of the form has different verification rules.

For example, in the Name box, you need to verify non-null, sensitive words, and long characters. Of course, three if else codes can be written, but the scalability and maintainability of codes can be imagined. If there are more elements in the form, there are more verification cases. It is not impossible to add up to hundreds of if else statements.

Therefore, it is better to encapsulate each verification rule in a policy mode. You only need to provide the name of the policy for which authentication is required. Like this:

NameInput. addValidata ({notNull: true, dirtyWords: true, maxLength: 30}) and notNull, maxLength, and other methods only need to return true or false in a unified manner to indicate whether the verification has passed. ValidataList = {notNull: function (value) {return value! = '';}, MaxLength: function (value, maxLen) {return value. length ()> maxLen ;}}

As you can see, various verification rules are easily modified and replaced. If the product manager recommends changing the length to 60 characters for a day. It takes 0.5 seconds to complete the job.

The general content is introduced here.

Let's have a chat about the problem. It's coming soon in 2015. Are you sure you have a great year-end bonus !!!

I hope you can gain some gains over the past year. Through this article, you can also gain some gains, know what a strategy model is, and understand the two instances carefully prepared by xiaobian for everyone.