Traditional design pattern (i) policy model

Bugs used to be in a dealer's membership module where the classification is very clear

Different members have different permissions and behavior, most programmers use standard OO technology, design a member Super Class Superuser, and let a variety of merchant members inherit this super class

There's nothing wrong with that, but in the following process you can learn the difference between a strategic pattern and the way you write logical judgments in your code.

All members have the following behavior
Shopping, rating, publishing products

Public abstract class Superuser
    {public
        superuser ()
        {
        } public
        void shopping (
            ) { Console.WriteLine ("Shopping");
        }
        public void Comment ()
        {
            Console.WriteLine ("Comment");
        }
        public abstract void Promote ();
            
    }
    public class Usera:superuser
    {public
        override void Promote ()
        {
            Console.WriteLine ("Promote Category A Commodity");
        }
    }
    public class Userb:superuser
    {public
        override void Promote ()
        {
            Console.WriteLine ("Promote Class B Commodity");
    }

Because the different merchant member can only promote the specified type of goods, so here promote method abstract out

Okay, now we're here. A new requirement for users of Class B to discount their purchases

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/Programming/project/

Where do you add the Super class? No, not all of the Members have the logical judgment of discount? It's a way of doing it, but the change in demand is long and hold in a huge, bloated field model. Not to mention that there are a variety of merchant membership categories added in and a program that acts as a base station in a large web architecture is not suitable for frequent updates

Since this makes use of the interface how to turn the switch off to the extended open

public interface Discountbehavior {void Discount (); public class Diswithb:discountbehavior {public void Discount () {Console.wri
        Teline ("Can discount, uh"); } public class Nodis:discountbehavior {public void Discount () {Console.
        WriteLine ("no discount"); The public abstract class Superuser {public Superuser () {} is public void
        Shopping () {Console.WriteLine ("Shopping");
        public void Comment () {Console.WriteLine ("Comment");
    
        public abstract void Promote ();
        Public Discountbehavior Dcbehavior;
        public void Discount () {Dcbehavior.discount ();
            } public class Usera:superuser, Discountbehavior {public UserA () {
        Dcbehavior = new Nodis (); } PUBlic override void Promote () {Console.WriteLine ("Promotion of Category A commodities");  } public class Userb:superuser, Discountbehavior {public UserB () {Dcbehavior
        = new DISWITHB ();
        public override void Promote () {Console.WriteLine ("Promotion of Category B commodities"); }
    }

Now let's try the dynamic setting behavior again.

Add a method to the superclass

public void Setdiscountbehavior (Discountbehavior dh)
       {
           dcbehavior = DH;
       }

This way you can call this method "anytime" to change the behavior of a member

Summarize:

Policy mode: Programming for interfaces, not for implementation. Multi-use combination with less inheritance. The strategy pattern defines the algorithm clusters, which are packaged separately, so that they can be replaced by each other, and this pattern allows the algorithm to change independently from the client using the algorithm.

Author:cnblogs bugs that stay up late