Design Mode note-Strategy Mode VS simple factory Mode
Policy mode VS simple factory Mode
Strategy)It defines the algorithm family and encapsulates them separately so that they can replace each other. This pattern changes the algorithm and does not affect the customers who use the algorithm.
1. Composition
-Abstract policy role: a policy class, usually implemented by an interface or abstract class. -Specific policy roles: encapsulate related algorithms and behaviors. -Environment role: Hold a reference to the policy class and call it to the client. 2. Application Scenario-multiple classes only differ in different performance behaviors. You can use the Strategy Mode to dynamically select the behavior to be executed during running. -Different policies (algorithms) need to be used in different situations, or they may be implemented in other ways in the future. -Hides implementation details of specific policies (algorithms) from customers and is completely independent of each other.
First, let's take a look at the specific
It mainly includes two numbers: Number_X and Number_Y. The following are four operations: Add (+), Sub (-), Mul (*), and Div (/); when you select a mode and click an operation, the specific design mode is installed to instantiate the specific operation type.
The rule mode class diagram is as follows:
The specific implementation code is as follows:
// Policy base class public abstract class Strategy {// defines the virtual function public abstract double Result (double Number_x, double Number_y);} // addition operation public class Strategy_Add: strategy {public override double Result (double Number_x, double Number_y) {double number = 0; number = Number_x + Number_y; return number ;}// subtract public class Strategy_Sub: strategy {public override double Result (double Number_x, double Number_y) {double number = 0; number = Number_x-Number_y; return number ;}// multiplication public class Strategy_Mul: strategy {public override double Result (double Number_x, double Number_y) {double number = 0; number = Number_x * Number_y; return number ;}// division public class Strategy_Div: strategy {public override double Result (double Number_x, double Number_y) {double number = 0; if (Number_y = 0) return 0; number = Number_x/Number_y; return number ;}} // The specific object to be executed: public class Context {private Strategy strate; public Context (Strategy str) {this. strate = str;} public double GetResult (double Number_x, double Number_y) {return strate. result (Number_x, Number_y );}}
First, let's take a look at the differences between Virtual functions and Abstract Functions in the simple factory mode:
Both virtual and abstract are used to modify the parent class. By overwriting the definition of the parent class, the subclass is redefined.
They have one thing in common: if they are used to modify a method, public must be added before. Otherwise, a compilation error occurs: Virtual methods or abstract methods cannot be private. After all, adding virtual or abstract is to allow the subclass to be redefined, while private members cannot be accessed by the quilt class. However, they are quite different.
(1) virtual modifier methods must be implemented (even if only a pair of braces are added), while abstract modifier methods cannot.
(2) virtual can be overwritten by the quilt class, while abstract must be overwritten by the quilt class.
(3) If a class member is modified in abstract, abstract must be added before the class, because only abstract classes can have abstract methods.
(4) An abstract class instance cannot be created. It can only be inherited and cannot be instantiated. For example, BaseTest2 base2 = new BaseTest2 (); a compilation error occurs: the abstract class or interface cannot be used to create an instance.
(5) in C #, to override a method in a subclass, you must add virtual before the parent class method and override before the subclass method, this avoids the programmer from accidentally overwriting the parent class method in the subclass.
(6) abstract methods must be rewritten, and virtual methods must be implemented (even if they are defined in abstract classes ).
When recognizing the differences between the policy mode and the simple factory mode, Let's first look at the call methods of the two on the client.
Operation; // obtain the computing result private void GetResult_factory (string str) {response = null; response = FactoryOfOperation. getTheOperation (str); operation. number_x = Convert. toDouble (txt_x.Text.Trim (); optional. number_y = Convert. toDouble (txt_y.Text.Trim (); txt_result.Text = optional. result (). toString ();} Context cont; Strategy strate; // obtain the calculation result in Strategy Mode private void GetResult_strategy (string str) {strate = null; switch (str) {case add: strate = new Strategy_Add (); break; case sub: strate = new Strategy_Sub (); break; case mul: strate = new Strategy_Mul (); break; case div: strate = new Strategy_Div (); break; default: break;} cont = new Context (strate); txt_result.Text = cont. getResult (Convert. toDouble (txt_x.Text.Trim (), Convert. toDouble (txt_y.Text.Trim ())). toString ();}
From the client perspective, a simple Factory requires at least two classes. One is the Factory class Factory, which is used to generate a specific function class Operation, and the other is the Operation class, define the methods that can be overwritten in this Operation class. When using the client, you must first use the Factory class to generate a specific Operation class based on the client conditions, and then use the methods in the Operation class to implement specific functions; strategy class, there are two classes to be exposed on the client. One is the desired algorithm class Category, and the other is the Context class Context. The constructor of the Context class accepts a Category object, then, call the specific algorithm of this object to implement specific functions. The Context class is similar to the Factory class. Unlike the simple Factory mode, Context accepts an object and instantiates itself with this object, then call your own method. Of course, this method uses the method in this object. The Factory class accepts the condition to generate an object. The method of using this object still needs to call the method in this object, rather than the method in Factory. That is to say, the Factory is only responsible for obtaining objects. Context depends on a specific object to instantiate itself and call specific functional methods.