[Design mode-04] policy mode-significance for development and testing

The biggest difference between object-oriented and process-oriented is reusability and scalability. The reusability here is not only code-level reusability, but more importantly, module-level reusability. For a good object-oriented design, demand-oriented changes only need to be implemented by the change module. For more complex changes, you only need to add specific execution modules. If... else achieves some reusability at the code level, because it avoids code copying, but it needs to modify the code when it needs to change the execution process or add execution modules, it violates the "modification-oriented closed and expansion-oriented" principle in the five principles.

For TDD development, if... else, how many if... else needs to write the number of UT, and make sure that the execution in the if is done, but not in the else. In this way, the UT development workload is greatly increased. If the strategy mode is adopted, you only need to write one UT for the manager of the policy mode, which greatly reduces the UT development workload. At the same time, code reusability and scalability are greatly improved. In the face of complicated functional modules, the policy mode relies on interfaces, and Moq can be used to simulate specific situations. This is what if... else cannot do.

1. Usage of the policy mode

       Multiple related classes have different behaviors only.. These types are specific processing methods in several situations, such as red light stop, Green Light Line, yellow light, etc. Discounts are given to varying degrees based on membership levels.

       Different variants of an algorithm are required.For example, for a data set, sorting and statistical analysis for certain columns, such as statistics on gender, age, and major.

       Algorithms use data that customers should not know.After the policy mode is used, the client value comes into contact with the Manager class, and you only need to input a reference to a specific operation class. The implementation details are hidden to ensure code security.

       A class defines multiple similar behaviors, and these behaviors appear in the form of multiple condition statements in the operations of this class.Move related condition branches into their respective Strategy classes to replace these condition statements.

       2. Rule mode structure

      

        Context): Use a ConcreteStrategy object for configuration. Maintain a reference to the Strategy object. You can define an interface to allow Strategy to access its data.
        Abstract Strategy): Defines the public interfaces of all supported algorithms. Context uses this interface to call a ConcreteStrategy-defined algorithm.
        ConcreteStrategy): Implement a specific algorithm using the Strategy interface.

AlgorithmContext class

Namespace StrategyPatternDemo {public class AlgorithmContext {private IAlgorithmInterface algorithmInterface; public AlgorithmContext (IAlgorithmInterface algorithmInterface) {this. algorithmInterface = algorithmInterface;} public string DoStrategyAlgorithm () {return algorithmInterface. doAlgorithm ();}}}

ConcreteStrategyA class

Namespace StrategyPatternDemo {class ConcreteStrategyA: IAlgorithmInterface {public string DoAlgorithm () {return "StrategyA ";}}}

ConcreteStrategyB class

Namespace StrategyPatternDemo {class ConcreteStrategyB: IAlgorithmInterface {public string DoAlgorithm () {return "StrategyB ";}}}

ConcreteStrategyC class

Namespace StrategyPatternDemo {class ConcreteStrategyC: IAlgorithmInterface {public string DoAlgorithm () {return "StrategyC ";}}}

IAlgorithmInterface interface

Namespace StrategyPatternDemo {public interface IAlgorithmInterface {string DoAlgorithm ();}}

Unit test

Namespace StrategyPatternTestProject {// <summary> /// This is the test class of AlgorithmContextTest, purpose: // include all AlgorithmContextTest unit tests /// </summary> [TestClass] public class extends {private AlgorithmContext algorithmContext; private IAlgorithmInterface algorithmInterface; private string extends T; private string actual; [TestInitialize] public void Initalize () {algorithmInterface = new ConcreteStrategyA (); algorithmContext = new AlgorithmContext (algorithmInterface); counter t = "StrategyA ";} /// <summary> /// DoStrategyAlgorithm test /// </summary> [TestMethod] public void DoStrategyAlgorithmTest () {actual = algorithmContext. doStrategyAlgorithm (); Assert. areEqual (effect, actual);} [TestCleanup] public void CleanUp (){}}}

Test structure

3. Advantages and disadvantages of the policy mode:

Callers must clearly understand the specific behaviors and differences of each policy. From the code perspective, many policy classes will be added. But the advantage is that you do not need to change the code for the extension. You only need to add modules.

[Design mode-04] policy mode-significance for development and testing