[design notes] 234

[design notes] 234

2 Strategy

brief introduction

In general shopping malls, there are many promotion modes, including normal mode, how much to return when full, and how much to discount directly. Different amounts need to be charged according to different modes.

You can use the simple factory mode to design a CashFactory, and then set subcategories according to the discount situation: normal mode CashNormal, discount charge subcategory CashRebate, rebate charge subcategory CashSuper. You can call different subcategories in the factory.

Although a simple factory can also solve the problem, this model only solves the problem of object creation. Moreover, since the factory itself includes all charging methods, shopping malls may often change the discount amount and rebate amount, such as the promotion means of 100 points and 10 points. The factory needs to be changed every time the charging method is maintained or expanded, so the code needs to be recompiled and deployed, so it is not the best way.

Strategy mode: it defines the algorithm family and encapsulates them separately so that they can be replaced with each other. This mode makes the change of the algorithm not affect the customers using the algorithm.

using System;

namespace NS_Strategy
{
    class Program
    {
        // Abstract algorithm class
        abstract class Strategy
        {
            //Algorithm method
            public abstract void AlgorithmInterface();
        }
        
        //   ConcreteStrategy encapsulates specific algorithms or behaviors and inherits from Strategy//

        // Specific algorithm class A
        class ConcreteStrategyA : Strategy
        {
            //Specific implementation method of algorithm A
            public override void AlgorithmInterface()
            {
                Console.WriteLine("algorithm A Concrete implementation");
            }
        }

        // Specific algorithm class B
        class ConcreteStrategyB : Strategy
        {
            //Specific implementation method of algorithm A
            public override void AlgorithmInterface()
            {
                Console.WriteLine("algorithm B Concrete implementation");
            }
        }

        // Specific algorithm class C
        class ConcreteStrategyC : Strategy
        {
            //Specific implementation method of algorithm A
            public override void AlgorithmInterface()
            {
                Console.WriteLine("algorithm C Concrete implementation");
            }
        }

        //   Context is configured with a ConcreteStrategy and maintains a reference to the Strategy object//

        // context
        class Context
        {
            Strategy strategy;
            public Context(Strategy strategy)
            {
                this.strategy = strategy;
            }

            // Context interface
            public void ContextInterface()
            {
                strategy.AlgorithmInterface();
            }
        }

         Client code  //
        static void Main(string[] args)
        {
            Context context;

            context = new Context(new ConcreteStrategyA());  // Instantiate different strategies
            context.ContextInterface();

            context = new Context(new ConcreteStrategyB());
            context.ContextInterface();

            context = new Context(new ConcreteStrategyC());
            context.ContextInterface();

            Console.Read();
        }
    }
}

Of course, you can combine the simple factory with the policy mode. At the client, change the input of the Context into the characters or conditions to be judged, and then directly call different algorithms without instantiating them in turn at the client. The responsibility of selecting the specific implementation can be borne by the Context, which minimizes the responsibility of the client.

Policy mode is a method to define a series of algorithms. Conceptually, all these algorithms complete the same work, but the implementation is different. All algorithms can be called in the same way, reducing the coupling between various algorithms and algorithm classes.

The policy pattern * * * * simplifies unit testing because each algorithm has its own class and can be tested separately through its own interface.

3 single responsibility principle (SRP)

As far as a class is concerned, there should be only one reason for its change.

No matter what kind of form you need to change, it's more troublesome to add a form class. No matter what kind of form you need to change, you don't need to change it.

If a class assumes too many responsibilities, it is equivalent to coupling these responsibilities. The change of one responsibility may weaken or inhibit the ability of this class to complete other responsibilities. This coupling will lead to fragile design. When changes occur, the design will be destroyed unexpectedly.

Much of what software design really needs to do is to find responsibilities and separate those responsibilities from each other.

If you can think of more than one motivation to change a class, then the class has more than one responsibility, and the separation of responsibilities of the class should be considered.

Now the responsibilities of mobile phones are more and more tired. Is it too much responsibility? Mobile phones are easy to carry. If the volume of DV,MP3 and other products can be reduced by 100 times, like bank cards or holographic projection, the functions of mobile phones will be cumbersome at that time. Now mobile phones are excessive products.

4. Open closed principle

Software entities (classes, modules, functions, etc.) should be extensible, but not modifiable.

There are two characteristics:

  • open for extension
  • closed for modification

The open closed principle is the core of object-oriented design. Following this principle can make the program maintainable, extensible, reusable and flexible. Developers should abstract only those parts of the program that appear to change frequently.

It is not a good idea to abstract every part of the program. Rejecting immature abstraction is as important as abstraction itself.

above.

Tags: C# Design Pattern

Posted by Eric_Ryk on Fri, 20 May 2022 05:00:39 +0300