C # design Pattern 1: Policy mode

The first thing to note is that all of the contents of the series are described based on the headfirst design pattern. Because I've seen a lot of books about design patterns before, or the best of all, because the examples given in this book are the most relevant. Don't say, start this series!

Policy mode

design principles ①: Find out where you might need to change in your application, separate them, and don't mix with the unchanging code. Extract the parts that will change so that you can easily expand or change this part later without affecting the unchanging part of the code. As a result, the unintended consequences of code changes become less and the system becomes more resilient.

Design Principle ②: Programming for interfaces, not for implementations. From now on, the changing part is abstracted into the interface so that the duck does not have to know the specific implementation of the behavior.

Design principle ③: Multi-use combination, less inheritance.

The policy pattern definition : Defines the algorithm family, encapsulates separately, lets them each other can replace. This pattern allows the algorithm to change independently of the customer using the algorithm.

background : Joe has designed a duck game in which all ducks have a base class, and all ducks inherit consistent behavior from this base class, but the design ignores one important factor: change . not all subclasses have similar behavior, and the world is no longer wonderful.

The following is the design of the duck game for this model:

  Public Abstract classDuck { Public stringColor {Get;Set; }  Public stringName {Get;Set; }//Suppose a duck has a name            Privateiquackable _quackable; Privateiflyable _flyable; protectedDuck (iquackable quack,iflyable fly) {_quackable=Quack; _flyable=Fly; }             Public Override stringToString () {return$"My name is {name},i am {Color}"; }             Public Virtual voidSwim () {Console.WriteLine ("All duck can swim"); }        } Public Interfaceiquackable {voidQuack (); }         Public Interfaceiflyable {voidFly (); }         Public classicanquack:iquackable { Public voidQuack () {Console.WriteLine ("I can quack"); }        }         Public classicanfly:iflyable { Public voidFly () {Console.WriteLine ("I Can fly"); }        }

First, a base class was designed for ducks, and this base class is an abstract class, and all the other ducks will inherit from here. What is important is that the ducks are called and fly these two behaviors are pulled out, made an interface, because not all ducks will fly, and not all ducks will be called. In this way, when defining a duck subclass, we can program the characteristics of the duck. It also improves the elasticity of the system. Among them, some of the behavior of ducks independent of the above-mentioned design principles in the ①,duck class is for two interfaces to obtain specific behavior this conforms to the design principle ②, the two interfaces as Duck field conforms to the design principle ③.

C # design Pattern 1: Policy mode