心之所向，身之所往

1、建造者模式 2、代码 #include #include using namespace std; class PersonBuilder { public:     virtual void BuildHead() = 0; virtual void BuildBody() = 0; virtual void BuildArm() = 0; virtual

将抽象部分与它的实现部分分离，使它们都可以独立地变化。考虑装操作系统，有多种配置的计算机，同样也有多款操作系统。如何运用桥接模式呢？可以将操作系统和计算机分别抽象出来，让它们各自发展，减少它们的耦合度。当然了，两者之间有标准的接口。这样设计，不论是对于计算机，还是操作系统都是非常有利的。        //操作系统 class OS { public: virtual v

案例：星巴克咖啡销售系统         饮料由 原料（咖啡） 和 调料（Milk 、Mocha等）组成，价格由原料和调料的价格相加。原料有多种，调料也有多种，所有就有多种不同的组合。 设计：类爆炸式设计 问题：如果原料和调料增加，将使类的个数成指数增长。 装饰者模式设计： 代码： #include #include using namespace std;

外观模式应该是用的很多的一种模式，特别是当一个系统很复杂时，系统提供给客户的是一个简单的对外接口，而把里面复杂的结构都封装了起来。客户只需使用这些简单接口就能使用这个系统，而不需要关注内部复杂的结构。DP一书的定义：为子系统中的一组接口提供一个一致的界面， 外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。举个编译器的例子，假设编译一个程序需要经过四个步骤：词法分析、语法分析、中间代

1、代理模式 2、代理模式的要点 （1） 代理模式与真实对象有同样的接口，这样保证在任何使用 RealSubject 的地方都可以使用 Proxy。 （2） Proxy 保存一个真实象的引用，这样可以访问 RealSubject 对象。 3、代码 #include #include using namespace std; class S

1、模板方法 2、代码 #include using namespace std; class AbstractClass { public: virtual void PrimitiveOperation1() { printf("AbstractClass PrimitiveOperation1\n"); } virtual void PrimitiveOper

结构性模式：处理多个类组合的关系。 动机：一些现存在的对象放在新环境中，新环境要求的 接口是这个现存的对象不满足的。 定义：适配器模式将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。它包括类适配器和对象适配器。 对象适配器： #include #include using namespace std; //这个是需要适配的

案例：鸭子游戏            有两种鸭子，MallardDuck和RedheadDuck，鸭子的行为有Quack 和 swim 和fly 和display。两种鸭子的Quack、Swim、Fly 行为是一样的，display则不同。 设计：       变化： 1、要让MallardDuck鸭子可以Fly，但是RedheadDuck不可以Fly这么办？ 2、两种鸭子Quck、S

1、定义：一个对象状态改变时（目标对象），所有依赖他的对象（观察者对象）都需要发生改变。 示例：有一个Sender类，负责数据的发送，Display类和Media类都需要调用Sender类中的方法进行数据发送，当网络连接断开时，需要通知Display和Media类停止数据发送。 紧耦合设计： #include #include using namespace std; class Di

class Handle { public:  Handle(){}  virtual ~Handle(){}  void SetSuccessor(Handle* successor)  //设置后继,这里必须用指针，只是声明，没有去定义。  {   this->h_hander = successor;  }  virtual void HandleRequest(int r

1、原型模式 2、代码 #include using namespace std; class Resume { protected: char* name;// 名字不会变 int age;  //年龄可能会变 public: Resume() { } virtual ~Resume() { } virtual Resume* Clone()

1、外观模式 2、代码 #include #include using namespace std; class Stock1 { public: void sell() { printf("sell stock1\n"); } void buy() { printf("buy stock1\n"); } }; class Stock2 {

定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。 问题由来：在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。 解决方案：当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。          开闭原则是面

设计模式六大原则（2）：里氏替换原则 .  (2012-07-03 15:18:37) 转载▼ 标签：  设计模式   里氏替换   it 分类： 设计模式 肯定有不少人跟我刚看到这项原则的时候一样，对这个原则的名字充满疑惑。其实原因就是这项原则最早是在1988年，由麻省理工学院的一位姓里的女士（Barbara L

1、抽象工厂模式 2、代码 #include using namespace std; class OldOperation; class NewOperation; class AddOne; class AddTwo; class SubOne; class SubTwo; class OldOperation { public: virtu

工厂方法模式 代码： #include using namespace std; class Operation { public: virtual int process(int a,int b); }; int Operation::process(int a,int b) { return 0; } class AddOperation:pub

简单工厂模式： 代码： #include using namespace std; class Operation { public: virtual int process(int a,int b); }; int Operation::process(int a,int b) { return 0; } class AddOperation:pu

定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。 问题由来：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。 解决方案：将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。 举例来说明接口隔离原则： ."

定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。 问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。 解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接

定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。 问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。 解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T

定义：一个对象应该对其他对象保持最少的了解。 问题由来：类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。 解决方案：尽量降低类与类之间的耦合。          自从我们接触编程开始，就知道了软件编程的总的原则：低耦合，高内聚。无论是面向过程编程还是面向对象编程，只有使各个模块之间的耦合尽量的低，才能提高代码的复用率。低耦合的优点不言而喻，但是怎么

#include      /* printf */ class Singletest { public:     static Singletest* getinstace();     ~Singletest(); private:     Singletest();  static Singletest* instance;  }; Singletest* Si