Understanding of Design Patterns: Strategy Patterns

The strategy model, also known as the policy model, is an object behavior model. Define a series of algorithms, encapsulate them with classes one by one, and make them replace each other. In this mode, the algorithm can be independent of the client program that uses and uses it.

The implementation is: class inheritance and polymorphism to create objects

For example, in the implementation of algorithms, different branches should be taken according to different situations. Each branch does the same algorithm but is independent.

For example, regarding a method of calculating taxation, to support tax calculations in China, Japan, and the United States, there are two ways to achieve it:

enum countryType{
 CN,
 US,
 JP
}
class ctax{
public:
countryType type;
int caltax (Object param){
    switch(type){
    case CN:
        //中国的税务计算
        break;
    case US:
        //美国的税务计算
        break;
    case JP:
        //日本的税务计算
        break;
    default：
        .....
    }
  
}

The second type:

class taxStrategy{
    virtual int caltax (Object param)=0;
}
class cnTaxStrategy:pubilc taxStrategy{
    virtual int caltax (Object param){/**中国的税务计算**/};
}
class usTaxStrategy:pubilc taxStrategy{
countryType type;
    virtual int caltax (Object param){/**美国的税务计算**/};
}
class jpTaxStrategy:pubilc taxStrategy{
countryType type;
    virtual int caltax (Object param){/**日本的税务计算**/};
}


class ctax{
public:
countryType type;
int caltax (Object param){
   taxStrategy* strategy = newStrategy(); //创建实体
   strategy->caltax(param) ;
}

In both cases, the client's application is ctax. If there is a demand for "new UK taxation algorithm", then the first type of code is to add an enumeration and extend the implementation of switch...case.. The second method needs to create a new derived class and extend the object instantiation method newStrategy().

Although in terms of functional requirements, both methods can be implemented. But in terms of maintainability, there is no doubt that the first method is relatively poor. If the algorithm complexity is too high, or there will be an expansion of the tax needs of different countries in the future. Then the first method will be implemented with a large amount of code, and the probability of production accidents caused by misoperation will increase. In terms of reusability, if other projects need to reuse tax codes, the first method can only be Ctrl CV, and the second method realizes the separation of algorithms and applications, which will not affect algorithm changes. The client program ctax. For another example, if this program is provided to a user in China, the Chinese user only needs China's taxation algorithm and does not need to support other countries' taxation. Then the first method will inevitably compile a large amount of useless algorithm code into the project, reducing performance.

Therefore, whenever you use if...elseif... or switch...case, you must consider whether the strategy mode is more suitable. Of course, it is appropriate to judge if...elseif.. with exhaustive conditions, such as gender, month. However, special considerations are required when judgments on conditions that cannot be exhaustive or judgment conditions change according to business needs. The main purpose of the strategy mode is to reduce the workload of code development, maintenance, and testing when new business requirements are added, and to reduce the scope of influence involved in the new requirements.

Understanding of Design Patterns: Strategy Patterns

Guess you like