Design mode (ii): Policy mode

UML Structural Analysis Diagram:

1#include <iostream>2#include <string.h>3#include <stdio.h>4#include <stdlib.h>5 using namespacestd;6 7 /*8 design Mode (ii): Policy mode9 define a series of algorithms, encapsulate them one by one, and allow them to replace each other. Ten This pattern allows the algorithm to be independent of the use of his customers. One */ A  -typedefenumstrategytype{Strategya, Strategyb, Strategyc}strategytype; - //Abstract algorithm strategy-base class the classStrategy - { -  Public: -     Virtual voidAlgorithminterface () =0; +     Virtual~strategy () {} - }; +  A classConcretstrategya: PublicStrategy at { -  Public: -     voidAlgorithminterface () {cout <<"I am from Concretstrategya"<<Endl;} -~Concretstrategya () {} - }; -  in classCONCRETSTRATEGYB: PublicStrategy - { to  Public: +     voidAlgorithminterface () {cout <<"I am from Concretstrategyb"<<Endl;} -~Concretstrategyb () {} the }; *  $ classCONCRETSTRATEGYC: PublicStrategyPanax Notoginseng { -  Public: the     voidAlgorithminterface () {cout <<"I am from CONCRETSTRATEGYC"<<Endl;} +~Concretstrategyc () {} A }; the  +  - classContext $ { $  Public: - Context (strategytype strategytype) -     { the         Switch(Strategytype) -         {Wuyi          CaseStrategya: theStrategy =NewConcretstrategya (); -              Break; Wu          CaseStrategyb: -Strategy =Newconcretstrategyb (); About              Break; $          CaseSTRATEGYC: -Strategy =NewConcretstrategyc (); -              Break; -         default: AStrategy =NewConcretstrategya (); +              Break; the         } -     } $  the~Context () the     { the         if(strategy) the             Deletestrategy; -     } in  the     voidGetInterface () the     { About         if(strategy) theStrategy->algorithminterface (); the     } the Private: +strategy*strategy; -  the };Bayi  the intMainintargcChar**argv) the { -context* tmp =NewContext (Strategya); -Tmp->getinterface (); the     if(TMP) the         Deletetmp; theSystem"Pause"); the     return 0; -}

Note: The strategy mode and the state mode are very similar, the state pattern is about the change of state, and the different behavior in different states, while the policy mode focuses on the same action, the algorithm that implements the behavior differs, and different strategies encapsulate different algorithms. The policy pattern is suitable for implementing a function, and the algorithm that implements it is a frequently changing situation. In the actual work, encountered the actual scene, may have the deeper experience. For example, we do a certain system, the system can be applied to a variety of databases, we all know that the way to connect a database is not the same, it can be said that the database connection "algorithm" is not the same. In this way, we can use the policy mode to implement different policies for connecting the database, so as to realize the dynamic transformation of the database.

Principles of the policy model:

Single principle of responsibility

As far as a class is concerned, there should be only one cause for it to change.

If a class takes on too much responsibility, it is tantamount to coupling these responsibilities, and a change in responsibility may weaken or inhibit the ability of the class to perform other duties. This coupling leads to fragile designs that can be subjected to unexpected damage when changes occur.

If you can think of more than one motive to change a class, then this class has more than one responsibility.

Openness-the principle of closure

Software entities can be extended, but cannot be modified. That is, the extension is open, and the modification is closed. In the face of demand, changes to the program are done by adding code, rather than altering the existing code.

When changes occur, we create abstractions to isolate changes that happen in the future.

The open-closed principle is the core of object-oriented. Developers should abstract the part of the program that is showing frequent changes and reject the abstraction that is deliberately abstract and immature for any part.

Principle of substitution on the Richter scale

If a software entity is using a parent class, its subclasses must be applied. And it does not recognize the difference between a parent object and a subclass object. In other words: In the software, the parent class is replaced with subclasses, and the behavior of the program does not change.

Subtypes must be able to replace their parent types.

Dependency reversal principle

Abstractions should not depend on detail, and detail should be dependent on abstraction. That is, for interface programming, do not program the implementation.

The high-level module cannot rely on the lower layer, both of which should be abstract.

The dependency reversal principle is an object-oriented flag, and it is not important to write a program in which language, if you are writing, consider how to program on abstract programming rather than on details, that is, all of the dependencies of a program terminate in an abstract class or interface. That is object-oriented design, which is the process of design.

Reference Blog: http://www.jellythink.com/archives/388

Design mode (ii): Policy mode