This is the 10th day of my participation in the August More Text Challenge. For details, see:August is more challenging

  • 📢 welcome to like: 👍 collect ⭐ message 📝 If there is any mistake please correct it, send roses, hand left fragrance!
  • 📢 This article is written by Webmote.
  • 📢 author’s motto: life lies in tossing about, when you do not toss about life, life will start tossing you, let us work together! 💪 💪 💪

🎏 01. Proxy mode

Intent: Define a set of algorithms designed to be interchangeable with each other.

Figuratively speaking: although the algorithm is different, the client execution call does not need to be modified. Different algorithms, like different policies, can be replaced at any time.

Problem areas:

  • There are a lot of different algorithms that don’t want to be hard-coded into the system,
  • The algorithms can be interchangeable depending on the situation,
  • Other data in the algorithm that you don’t want exposed,
  • Old system refactoring, found many if branch statements, can consider replacement

Solution: We use UML diagrams to describe this.

We define an interface, or abstract class Strategy, and design its interface, with concrete implementation classes implementing different algorithms, in this case ConcreteStrategy1 and 2.

Client is a user, which can instantiate the Strategy class internally, and can also configure different Strategy classes according to conditions. Specific application methods are invoked through interfaces or abstract classes, so as to avoid directly selecting concrete classes.


  • Benefits:
  1. The algorithm series can be expanded;
  2. An alternative to direct inheritance is to avoid hard-coding the algorithm into the use class.
  3. Eliminate branch statements;
  4. Customers can have a variety of choices;
  • Limit:
  1. Customers need to know the differences between algorithms.
  2. Increased the number of objects

🎏 02. Dotnet Core source code appreciation

In the Aspnet Core source code, there is an interface IValidationStrategy that validates the policy, using the policy pattern.

public interface IValidationStrategy
        IEnumerator<ValidationEntry> GetChildren(ModelMetadata metadata, string key, object model);
    internal class DefaultComplexObjectValidationStrategy : IValidationStrategy

        public static readonly IValidationStrategy Instance = new DefaultComplexObjectValidationStrategy();

        private DefaultComplexObjectValidationStrategy(){}/// <inheritdoc />
        public IEnumerator<ValidationEntry> GetChildren(
            ModelMetadata metadata,
            string key,
            object model)
            return newEnumerator(metadata, key, model); }}}Copy the code

The strategy pattern is not difficult to understand and can be introduced in the right scenario.

🎏 03. dotnet proxy class implementation

As an example, let’s implement a policy class based on the design of the UML diagram. The interface is defined as follows:

public abstract class Strategy
        public abstract void AlgorithmInterface();
    public class ConcreteStrategyA : Strategy
        public override void AlgorithmInterface()
                "Called ConcreteStrategyA.AlgorithmInterface()"); }}public class ConcreteStrategyB : Strategy
        public override void AlgorithmInterface()
                "Called ConcreteStrategyB.AlgorithmInterface()"); }}public class Client
        Strategy strategy;
        // Constructor
        public Client(Strategy strategy)
            this.strategy = strategy;
        public void ContextInterface(){ strategy.AlgorithmInterface(); }}Copy the code

Callers, which can be used directly as follows.

Client context;
// Two contexts following different strategies
context = new Client(new ConcreteStrategyA());
context = new Client(new ConcreteStrategyB());
Copy the code

Yes, through the above policy class, we can switch the policy implementation class at will in the client code to achieve the purpose of exchange. Of course, if the configuration information is introduced, the algorithm can be dynamically modified according to the configuration information.

Your project has a similar scene, can be used to practice hand oh.

🎏 04. Summary

Policy patterns focus on achieving the same goal through different algorithms. The focus is mainly on the abstraction of behavior, so policy patterns are generally based on interfaces.

The design patterns in each article are easy to look at, but often very hard to write. This is probably because I don’t use them in most of my programming scenarios, or I use them less often. Even the patterns that aren’t on the top of the list may never be used.

Of course, looking at the.NET source code and trying to find the design patterns we need is not an easy job.

While much has been written about design patterns, I wanted to write something different, both to strengthen my memory and to programmers a pep talk about how many design patterns we can learn from Core source code that underpins us.

So can look at the source code programmer will not be bad to where to go! 😳

Routine summary, rational view!

Knot is what, knot is I want you to like but can not get the loneliness. 😳 😳 😳

👓 all see this, still care to point a like?

👓 all points like, still care about a collection?

Do you care about a comment when you have collected 👓?