个人独立博客http://www.acb0y.cn/

简单工厂设计模式：也就是说，到底要实例化谁，将来会不会增加实例化的对象，这是很容易发生变化的地方，应该考虑用一个单独的类来做这个创建实例的过程，这就是工厂。C++实现代码如下：/* Author: ACb0y Create Time: 2010年12月2日15:00:28 Model: simpleFactory */#include using namespace std;/* 运算类 */class Operation{public: //左值

适配器模式<br />     适配器模式（Apater）将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。<br />     适配器模式主要解决什么问题呢？<br />     答：简单地说，就是需要的东西就在面前，但却不能使用，而短时间又无法改造它，于是我们就想办法适配它。<br />     系统的数据和行为都正确，但接口不符合时，我们应该考虑用适配器，目的是使控制范围之外的一个原有对象与某个接口匹配。适配器模式主要应用于希望复用

备忘录模式<br />    备忘录模式（Memento）：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。<br />     Originator（发起人）：负责创建一个备忘录Memento，用以记录当前时刻它的内部状态，并可以使用备忘录恢复内部状态。Originator可根据需要决定Memento存储Originator的那些内部状态。<br />      Memento（备忘录）：负责存储Originator对象内部状态，并可防

组合模式<br />   组合模式(Composite)将对象组合成树形结构已表示‘部分-整体’的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。 <br />UML图如下：<br /><br />C++代码实现如下：<br />/* Autohr： ACb0y Date：2010年12月20日16:37:17 Model：Composite（组合模式） */#include <iostream>#include <string>#include <vecto

迭代器模式<br />       迭代器模式（Iterator），提供一种方法顺序访问一个聚合对象中各个元素，而不是暴露该对象的内部表示。<br />     一个聚集对象，而且不管这些对象是什么都需要遍历的时候，你就应该考虑用迭代器模式。你需要对聚集有多种方式遍历时，可以考虑用迭代器模式。为遍历不同的聚集结构提供如开始，下一个，是否结束，当前哪一项等统一的接口。<br />UML图如下：<br /><br />C++实现代码如下：<br />/* Author: ACb0y Date: 2010

单例模式<br />       单例模式(Singleton)，保证一个类仅有一个实例，并提供一个访问它的全局访问点。<br />通常我们可以让一个全局变量使得一个对象被访问，但它不能防止你实例化多个对象。一个最好的办法就是，让类自身负责保存它的唯一实例。这个类可以保证没有其他实例可以被创建，并且它可以提供一个访问该实例的方法。<br />UML图如下：<br /><br />C++代码实现如下：<br />/* Author: ACb0y Date: 2010年12月21日11:10:16

合成/聚合复用原则      合成/聚合复用原则（CARP），尽量使用合成/聚合，不要使用类继承。     合成（Composition，也有翻译成组合）和聚合（Aggregation），都是关联的特殊种类。聚合表示一种弱的“拥有”关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分；合成（组合）是一种强的“拥有”关系，体现了严格的部分与整体的关系，部分和整体的生命周期是一样的。     例如下面UML 描述：    优先使用对象的合成/聚合将有助于你保持每个类被封装，并被集中在单个任务上。这样类

桥接模式<br />      桥接模式(Bridge)，将抽象部分与它的实现部分分离，使它们都可以独立地变化。<br />什么叫抽象与它的实现分离，这并不是说，让抽象类与其派生类分离，因为这没有任何意义。实现指的是抽象类和它的派生类用来实现自己的对象。<br />      由于实现的方式多种，桥接模式的核心意图就是把这些实现独立出来，让它们各自地变化。这样就使得每种实现的变化不会影响其他实现，从而达到应对变化的目的。<br />     实现系统可能要多角度分类，每一种分类都有可能变化，那么就把这种多角

中介者模式     一系列的对象交互。中介者使各对象不需要显示相互引用，从而使其耦合松散，而且可以独立地变化它们之间的交互。UML图如下：C++代码实现如下：/* Author: ACb0y Date: 2011年1月8日19:45:25 Model: Mediator */#include #include using namespace std;class Colleague;/* Mediator类，抽象中介者类 */class Mediator {

责任链模式     责任链模式：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。奖这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。UML图如下：C++实习代码如下：/* Author: ACb0y Date: 2011年1月8日17:11:17 Model: chain of responsibility（责任链模式） */#include using namespace std;/* Handler类，定义一个处理请求的接口

享元模式     享元模式运用共享技术有效地支持大量细粒度的对象。UML图如下：C++代码实现如下：#include #include using namespace std;/* Flyweight类，它是所有具体享元类的 超类或接口，通过这个接口，Flyweight 可以接受并作用于外部状态 */class Flyweight{public: char name[10]; virtual void Operation(int) = 0;};/*

状态模式<br />      状态模式(State)，当一个对象的内在状态改变时，允许改变其行为，这个对象看起来像是改变了其类。<br />状态模式主要解决的是当控制一个对象的状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑移到表示不同状态的一系列类当中，可以把复杂的判断逻辑简化。<br />UML图如下：<br /><br />C++代码实现如下：<br />/* Author: ACb0y Date: 2010年12月18日21:33:26 Model: State（状态模式）

<br />观察者模式<br />      观察者模式又叫做发布-订阅(Publish/Subscribe)模式。<br />观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一主题对象，这个主题对象在状态发生变化时，会通知所有观察者对象，使它们能够自动更新自己。<br /> <br />UML图如下：<br />C++实现代码如下：<br />/* Author: ACb0y Date: 2010-12-17 Model: Observer */#include <io

抽象工厂模式<br />      抽象工厂模式（Abstract Factory）提高一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。<br />      AbstractProductA和AbstractProductB是两个抽象产品，之所以为抽象，是因为它们都有可能有两种不同的实现。<br />     AbstractFactory是一个抽象工厂接口，它里面应该包含所有的产品创建的抽象方法。而ConcreteFactory1和ConcreteFactory2就是具体的工厂了。<br

开放-封闭原则<br />     软件设计的实体（类、模块、函数等等）应该可以扩展，但是不可以修改。就是说对于扩展是开放的，(open for extension)， 对于更改是封闭的(closed for modification)<br />     无论是模块是多么的‘封闭’，都会存在一些无法对之封闭的变化，既然不可能完全封闭，设计人员必须对于他设计的模块应该对那种变化进行封闭做出选择。作为一名优秀的软件设计者，要能预测出最有可能发生的变化种类，然后构造抽象来隔离哪些变化。<br />     变化

策略模式     策略模式定义了算法家族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。策略模式的结构图如下：策略模式剖析：     策略模式是一种定义一系列算法的方法，从概念上看，所有这些算法完成都是相同的工作，只是实现不同，它可以以相同的方式调用所有的算法，减少各种算法类与使用算法类之间的耦合。策略模式的Strategy类层次为Context定义了一系列可供重用的算法或行为。继承有助于抽象出这些算法的公共功能。      策略模式的优点是简化了单元测试，因为每个算法

依赖倒转原则<br />     抽象不应该依赖细节，细节应该依赖于抽象。换句话就是说，针对接口编程，不要针对实现编程。<br />     A:高层模块不应该依赖底层模块，两个都应该依赖抽象。B:抽象不应该依赖细节。细节应该依赖抽象。<br />     里氏代换原则：一个软件实体如果使用的是一个父类，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，在软件内部，把父类全部替换成子类程序的行为是不会发生改变的，简单地说，子类必须能够替换掉它们的父类型。<br />     只有当父类

/* */#include using namespace std;class LeiFeng{public: virtual void Sweep() { cout

简单工厂VS工厂方法<br />     简单工厂模式的最大优点在于工厂类中包含了必要的逻辑判断，根据客户端的选择条件动态实例化相关的类，对于一个客服端来说，去除了于具体产品的依赖，但是如果要加一个新的类来完成新的功能，我们是一定需要给运算工厂类的方法里加"case"的分支条件的，而这就修改了原来的类，从而违背了开放-封闭原则。<br />    对于变化的需求，工厂方法只需要增加相关的类和相应的工厂类就可以了，这样整个工厂和产品体系其实都没有修改的变化，而只是扩展了变化，这就完全符合了开放-封闭原则。<b

单一职责原则(SRP)<br />      就一个类而言，应该仅有一个引起它变化的原因。如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏性。<br />      软件设计真正要做到的许多内容，就是发现职责并把职责相互分离。<br />      如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责。

模板方法模式<br />    定义了一个操作中的算法的骨架，而将一些步骤延迟到了子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。<br />     当我们要完成在某一细节层次一致的一个过程或一系列步骤，但某个别步骤在更详细的层次上的实现可能不同时，我们通常考虑用模板方法来处理。<br /> <br />UML图如下：<br /><br /> <br />C++实现代码如下：<br /> <br />/* Author: ACb0y Date: 2010年12月16

外观模式<br />      为了系统中一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。<br /> <br />UML图如下：<br /><br /> <br />C++代码实现如下：<br /> <br />/* Author: ACb0y Date: 2010年12月16日12:29:59 Model: Facade（外观模式） */#include <iostream>using namespace std;class

装饰模式     动态地给一个对象添加一些额外的职责，就增加工能来说，装饰模式比生成子类更为灵活。Component是定义一个对象接口，可以这些对象动态添加职责。ConcreteComponent是定义了一个具体的对象，也可以给这个对象添加一些职责。Decorator装饰抽象类，继承了Component，从外类来扩展Component类的功能，但对于Component来说，是无需知道Decorator存在的。至于ConcreteDecorator就是具体的装饰对象起到给Component添加职责的功能。UM

代理模式    代理模式(Proxy)，为其他对象提供一种代理以控制对这个对象的访问。Subject类定义了RealSubject和Proxy的共用接口，这样就在任何使用RealSubject的地方都可以使用Proxy。UML图如下：C++实现代码如下：/* Author: ACb0y Date: 2010年12月15日18:32:26 Model: Decorator（装饰模式） */#include #include using namespace std;//抽

Hash-BinarySortTree在上一篇的文章中我对字符串常见的Hash函数进行了总结，在原来的代码中Hash的缓冲数组的元素是一条链表。即每个元素下“挂”的是一个单链表。我采用了设计模式中的策略模式对上次的代码进行了改造，把每个hash函数封装成一个类，这样程序更易于扩展和修改。除了对原来的代码进行重构之外，在Hash缓冲区数组中，每个元素下“挂”的不再是单链表，而是BinarySortTree（二叉排序树），本来想“挂”BalanceBinaryTree（平衡二叉树）后面考虑编程复杂度太大了，就没