标签:
UML结构分析图:
1 #include<iostream> 2 #include<string.h> 3 #include<stdio.h> 4 #include<stdlib.h> 5 using namespace std; 6 7 /* 8 设计模式(二):策略模式 9 定义一系列的算法,把他们一个个封装起来,并且使他们可相互替换。 10 该模式使得算法可独立于使用他的客户而变化. 11 */ 12 13 typedef enum StrategyType{ StrategyA, StrategyB, StrategyC }STRATEGYTYPE; 14 //抽象算法策略-基类 15 class Strategy 16 { 17 public: 18 virtual void AlgorithmInterface() = 0; 19 virtual ~Strategy(){} 20 }; 21 22 class ConcretStrategyA :public Strategy 23 { 24 public: 25 void AlgorithmInterface(){ cout << "I am from ConcretStrategyA" << endl; } 26 ~ConcretStrategyA(){} 27 }; 28 29 class ConcretStrategyB :public Strategy 30 { 31 public: 32 void AlgorithmInterface(){ cout << "I am from ConcretStrategyB" << endl; } 33 ~ConcretStrategyB(){} 34 }; 35 36 class ConcretStrategyC :public Strategy 37 { 38 public: 39 void AlgorithmInterface(){ cout << "I am from ConcretStrategyC" << endl; } 40 ~ConcretStrategyC(){} 41 }; 42 43 44 class Context 45 { 46 public: 47 Context(STRATEGYTYPE strategyType) 48 { 49 switch (strategyType) 50 { 51 case StrategyA: 52 strategy = new ConcretStrategyA(); 53 break; 54 case StrategyB: 55 strategy = new ConcretStrategyB(); 56 break; 57 case StrategyC: 58 strategy = new ConcretStrategyC(); 59 break; 60 default: 61 strategy = new ConcretStrategyA(); 62 break; 63 } 64 } 65 66 ~Context() 67 { 68 if (strategy) 69 delete strategy; 70 } 71 72 void GetInterface() 73 { 74 if (strategy) 75 strategy->AlgorithmInterface(); 76 } 77 private: 78 Strategy* strategy; 79 80 }; 81 82 int main(int argc,char** argv) 83 { 84 Context* tmp = new Context(StrategyA); 85 tmp->GetInterface(); 86 if (tmp) 87 delete tmp; 88 system("pause"); 89 return 0; 90 }
备注:策略模式和状态模式,是大同小异的;状态模式讲究的是状态的变化,和不同状态下,执行的不同行为;而策略模式侧重于同一个动作,实现该行为的算法的不同,不同的策略封装了不同的算法。策略模式适用于实现某一功能,而实现该功能的算法是经常改变的情况。在实际工作中,遇到了实际的场景,可能会有更深的体会。比如,我们做某一个系统,该系统可以适用于各种数据库,我们都知道,连接某一种数据库的方式是不一样的,也可以说,连接数据库的“算法”都是不一样的。这样,我们就可以使用策略模式来实现不同的连接数据库的策略,从而实现数据库的动态变换。
策略模式的原则:
单一职责原则
就一个类而言,应该仅有一个引起它变化的原因。
如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其它职责能力。这种耦合会导制脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏。
如果你能够想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责。
开放――封闭原则
软件实体可以扩展,但是不可修改。即对于扩展是开放的,对于修改是封闭的。面对需求,对程序的改动是通过增加代码来完成的,而不是改动现有的代码。
当变化发生时,我们就创建抽象来隔离以后发生同类的变化。
开放――封闭原则是面向对象的核心所在。开发人员应该对程序中呈现出频繁变化的那部分做出抽象,拒绝对任何部分都刻意抽象及不成熟的抽象。
里氏代换原则
一个软件实体如果使用的是一个父类的话,那么一定适用其子类。而且它察觉不出父类对象和子类对象的区别。也就是说:在软件里面,把父类替换成子类,程序的行为没有变化。
子类型必须能够替换掉它们的父类型。
依赖倒转原则
抽象不应该依赖细节,细节应该依赖抽象。即针对接口编程,不要对实现编程。
高层模块不能依赖低层模块,两者都应依赖抽象。
依赖倒转原则是面向对象的标志,用哪种语言编写程序不重要,如果编写时考虑的是如何针对抽象编程而不是针对细节编程,即程序的所有依赖关系都终止于抽象类或接口。那就是面向对象设计,反之那就是过程化设计。
参考博客:http://www.jellythink.com/archives/388
标签:
原文地址:http://www.cnblogs.com/jingliming/p/4745838.html