zhaopengvv的博客

设计模式学习笔记目录整理

使多个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递请求，直到有一个对象处理它为止。职责链模式的应用场合在于“一个请求可能有多个接受者，但是最后真正的接受者只有一个”，这个时候请求发送者与接受者的耦合有可能出现变化脆弱的症状，职责链的目的就是将二者解耦，从而更好地应对变化。应用了职责链模式后，对象的职责分派将更具有灵活性。我们可以在运行时动态添加或修改请求的处理职责。如果请求传递到职责链的末尾仍得不到处理，应该有一个合理的缺省机制。

提供一种方法顺序访问一个集合对象中的各个元素，而又不暴露（稳定）该对象的内部实现。迭代抽象：访问一个集合对象的内容而无需暴露它的内部表示。迭代多态：为遍历不同的集合结构提供一个统一的接口，从而支持同样的算法在不同的集合结构上进行操作。迭代器的健壮性考虑：遍历的同时更改迭代器所在的集合结构，会导致问题。（迭代器失效）

将对象组合成树形结构以表示“部分-整体”的层次结构。Composite使得用户对单个对象和组合对象的使用具有一致性（稳定）。Composite模式采用树形结构来实现普遍存在的对象容器，从而将“一对多”的关系转化为“一对一”的关系，使得客户代码可以一致地（复用）处理对象和对象容器，无需关系处理的是单个的对象，还是组合的对象容器。将“客户代码与复杂的对象容器结构”解耦是Composite的核心思想，解耦之后，客户代码将与纯粹的抽象接口——而非对象容器的内部实现结构——发生依赖，从而更能“应对变化”。...

学习笔记，设计模式之备忘录模式

1. 动机在软件构建过程中，某些对象的状态如果改变，其行为也会随之而发生变化，比如文档处于只读状态，其支持的行为和读写状态支持的行为就可能完全不同。如何在运行时根据对象的状态来透明地更改对象的行为？而不会为对象操作和状态转化之间引入紧耦合？enum NetworkState{ Network_Open, Network_Close, Network_Connect,};class NetworkProcessor{ NetworkState state;p

1. 动机在软件构建过程中，经常会出现多个对象互相关联交互的情况，对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将面临不断的变化。在这种情况下，我们可以使用一个“中介对象”来管理对象间的关联关系，避免相互交互的对象之间的紧耦合引用关系，从而可以更好地抵御变化。2. 模式定义用一个中介对象来封装（封装变化）一系列的对象交互。中介者使对象不需要显示的相互引用（编译时依赖->运行时依赖），从而使其耦合松散（管理变化），而且可以独立地改变他们之间的交互。3. 结

1. 动机在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。如何应对这种“迁移的变化”？如何既能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口？2. 适配器模式定义将一个类的接口转换为客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。3. 适配器结构图4. 适配器实现// 目标接口（新接口）class ITarget {public: vi

1. 动机在面向对象系统中，有些对象由于某种原因（对象的创建开销很大，或者某些操作需要安全控制，或者需要进程外的访问），直接访问会给使用者、或者系统结构带来很多麻烦。如何在不失去透明操作对象的同时，来管理、控制这些对象的复杂？增加一层间接层是软件开发中常见的解决方式。class ISubject {public: virtual void process();};class RealSubject : public ISubject {public: virtual vo

1. 动机上述A方案的问题在于组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战。如何简化外部客户程序和系统间的交互接口？如何将外部客户程序的演化和内部子系统的变化之间的依赖相互解耦？2. 门面模式定义为子系统中的一组接口提供一个一致（稳定）的界面，Facade模式定义了一个高层接口，这个接口使得这一系统更加容易使用（复用）。3. 门面模式模型图4. 总结要点从客户程序的角度来看，Facade模式简化了整个组件系统的接

1. 动机在软件系统中，经常面临着“某些结构复杂的对象”的创建工作，由于需求的变化，这些对象经常面临着剧烈的变化，但是它们却拥有比较稳定一致的接口。如何应对这种变化？如何向“客户程序”隔离出“这些易变的对象”，从而使得“依赖这些易变对象的程序”不随着需求变化而变化。// 抽象类class ISplitter { public: virtual void split() = 0; virtual ~ISplitter() {}}// 抽象工厂class ISpliterFa

1. 动机在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作；同时，由于需求的变化，往往存在更多系列对象的创建工作。如何应对这种变化？如何绕过常规的对象创建方法(new)，提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合？下面以访问数据库为例，访问数据库具有connection、command和reader 的创建工作，同时数据库分为Oracle、mysql和DB2等种类。class EmployeeDAO {public: vector<Emp

1. 动机在软件系统中，经常面临着创建对象的工作；由于需求的变化，需要创建的对象的具体类型经常变化。如何应对这种变化？如何绕过常规的对象创建方法(new)，提供一种“封装机制”来避免客户程序和这种“具体对象创建工作”的紧耦合？例如解决如下问题：MainForm 类创建分配器时依赖具体的BinarySpliter类，发生了紧耦合。class MainForm : public Form {public: void ButtonClick() { ISplitter

1. 动机由于某些类型的固有的实现逻辑，使得它们具有两个变化的维度，乃至多个纬度的变化。如何应对这种“多维度的变化”？如何利用面向对象技术来使得类型可以轻松地沿着两个乃至多个方向变化，而不引入额外的复杂度？class Messager {public: virtual void Login(string name, string passwd) = 0; virtual void SendMessage(string message) = 0; virtual void

1. 动机在某些情况下我们可能会“过度地使用继承来扩展对象的功能”，由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。如何使“对象功能的扩展”能够根据需要来动态地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使得任何“功能扩展变化”所导致的影响将为最低？以Stream流为例，实现文件流，内存流和网络流等主体业务，以及对这些主体业务进行扩展，一般的实现方式如下：// 业务操作class

1. 动机在软件构建过程中，我们需要为某些对象建立一种“通知依赖关系” ——一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。使用面向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系。从而实现软件体系结构的松耦合。以一个文件分割器为例，主窗口点击文件分割按钮，可以将一个文件分割为多个。另外，在分割的过程中需要展示分割的进度。class MainForm : public Form {private:

1. 动机在软件构建过程中，某些对象使用的算法可能多种多样，经常改变，如果将这些算法都编码到对象中，将会使对象变得异常复杂；而且有时候支持不使用的算法也是一个性能负担。如何在运行时根据需要透明地更改对象的算法？将算法与对象本 身解耦，从而避免上述问题？如下实例：enum TaxType{ CN_Tax, US_Tax, DE_Tax};class SalesOrder { TaxBase tax;public: double Calcula