sssssNian的专栏

//动态添加需求 //Decorator模式，又叫装饰模式，就是给一个对象额外地添加一些职责，以适应更多的变化。 //你或许写一个Door //的子类AlarmDoor ，在里面添加一个子类独有的方法alarm() 。而当你的系统仅仅在一两个地方使用了警报门，这明 //显是不合理的——虽然可以使用缺省适配器来弥补一下。 这时候，你可以考虑采用装饰模式来给门动态的添加些额外的功能。 /

//动态添加需求 //Decorator模式，又叫装饰模式，就是给一个对象额外地添加一些职责，以适应更多的变化。 //你或许写一个Door //的子类AlarmDoor ，在里面添加一个子类独有的方法alarm() 。而当你的系统仅仅在一两个地方使用了警报门，这明 //显是不合理的——虽然可以使用缺省适配器来弥补一下。 这时候，你可以考虑采用装饰模式来给门动态的添加些额外的功能。 /

//建造者模式 //定义 //将一个复杂对象的构造与它的表示分离，使同样的构建过程可以创建不同的表示，这样的设计模式被称为建造者模式。 //实用范围 //1 当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。 //2 当构造过程必须允许被构造的对象有不同表示时。 //角色 //在这样的设计模式中，有以下几个角色： //1 builder：为创建一个产品对象的各个部

//动态添加需求 //Decorator模式，又叫装饰模式，就是给一个对象额外地添加一些职责，以适应更多的变化。 //你或许写一个Door //的子类AlarmDoor ，在里面添加一个子类独有的方法alarm() 。而当你的系统仅仅在一两个地方使用了警报门，这明 //显是不合理的——虽然可以使用缺省适配器来弥补一下。 这时候，你可以考虑采用装饰模式来给门动态的添加些额外的功能。 /

// 观察者（Observer ）模式又名发布-订阅（Publish/Subscribe）模式。GOF  给观察者模 //式如下定义：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依 //赖于它的对象都得到通知并被自动更新。 //观察者模式的起源我觉得 应该是在 GUI 和业务数据的处理上 //观察者模式的组成部分。 //1)  抽象目标角色（Subject

//状态机  详细的在23种设计模式 4.2 //1) 使用环境（Context）角色：客户程序是通过它来满足自己的需求。它定义了客户程序需要的接口；并且维护一个具体状态角色的实例，这个实例来决定当前的状态。 //2) 状态（State）角色：定义一个接口以封装与使用环境角色的一个特定状态相关的行为。 //3) 具体状态（Concrete State）角色：实现状态角色定义的接口。 //G

//工厂模式 //工厂模式主要为创建对象提供过渡接口 以便将创建对象的过程屏蔽起来 //何时使用 //1、当客户程序不需要知道要使用对象的创建过程 //2、客户程序使用的对象存在变动的可能，或者根本不知道使用哪一个具体的对象 //工厂负责创造对象（new对象） #include #include      class Car { public: //默认私有 结构体默认公

//子系统发生的变化，很可 能要影响到客户类的调用。而且子系统在不断优化、可重用化的重构路上，会产生更多更小 //的类。这对使用子系统的客户类来说要完成一个工作流程，似乎要记住的接口太多了。 //    门面模式就是为了解决这种问题而产生的 //使用环境和优点 //     《设计模式》给出了门面模式的使用环境： //1)  当你要为一个复杂子系统提供一个简单接口时。在上面已经描

//单例（件）模式 //定义：保证一个类仅有一个实例，并提供一个访问他的全局访问点 //1、一个类的产生是由类构造函数完成的 使其私有化 外部就不能直接实例类对象 //2、提供一个访问单例的静态方法 //常用：工厂（因为系统我们就只有一个工厂来创建对象就可以了）..打印机的实例.. //系统方法库.. //不变单例对象（构造私有化不可被继承 保护可被继承产生多态） #includ

//详细的在23种设计模式 4.3 //1) 访问者角色（Visitor）：为该对象结构中具体元素角色声明一个访问操作接口。该操作 //接口的名字和参数标识了发送访问请求给具体访问者的具体元素角色。这样访问者就可 //以通过该元素角色的特定接口直接访问它。 //2) 具体访问者角色（Concrete Visitor）：实现每个由访问者角色（Visitor）声明的操作。 //3) 元素角色

//迭代器（Iterator）模式，又叫做游标（Cursor）模式。GOF给出的定义为：提供一种方法访问一个容器（container）对象中各个元素，而又不需暴露该对象的 //内部细节。 //在面向对象的软件设计中，我们经常会遇到一类集合对象，这类集合对象的内部结构可能有着各种各样的实现，但是归结起来，无非有两点是需要我们去关心的： //一是集合内部的数据存储结构，二是遍历集合内部的数据。面

//Adapter模式又叫适配器模式，顾名思义，这个模式就是把一个不能用的东西“适配”成可以用的东西。 //那么是如何“适配”的呢？比如，东西A想使用东西B，但是A没有能力（没法）使用B，怎么办？A就让东西C帮忙，A通过C就可以用B了。C如何帮忙呢？ //C一边可以通过一个“手柄”让A握住，A一用力，C就在另一边握住B的“手柄”，使用B。这样A就可以间接的使用到B了。 //A通过C使用B

//Mediator  模式提供将对象间 的交互和通讯封装在一个类中，各个对象间的通信不必显势去声明和引用，大大降低了系统 的复杂性能 // //例如 图中 ConcreteColleagueA 和 ConcreteColleagueB 之间的交互就可以通过 ConcreteMediator 提供的 //DoActionFromAtoB 来处理，ConcreteColleagueA 和

1）钟爱组合而不是继承，2）钟爱接口而不是实现