静故了群动

根据Linda Rising的《Pattern Almanac》一书，已知的架构模式有七十多种。这是一个只多不少的统计，其中包括了很多通常认为是设计模式的模式，比如Bridge，Facade，Interpreter，Mediator等模式通常认为是设计模式，但是在许多情况下，也可以作为架构模式出现，因此也常常被当作架构模式。　　Layers架构模式　　在收集到用户对软件的要求之后，架构设计就开始了

GOOD：在当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时适用。（P115页）例：#include #include #include using namespace std; //最终的产品类class Product {private:       vector m_product;public:       vo

GOOD：当一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为时，可考虑用到状态模式。例#include using namespace std; class Work;class ForenoonState;class NoonState; class State{public:       virtual void Write

GOOD：双方都不适合修改的时候，可以考虑使用适配器模式例：#include using namespace std; class Target{public:       virtual void Request()       {              cout普通的请求"       }}; class Adaptee{

GOOD：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样就可以将以后的对象状态恢复到先前保存的状态。适用于功能比较复杂的，但需要记录或维护属性历史的类；或者需要保存的属性只是众多属性中的一小部分时Originator可以根据保存的Memo还原到前一状态。例：#include #include using namespace std;

GOOD：整体和部分可以被一致对待（如WORD中复制一个文字、一段文字、一篇文章都是一样的操作）例：#include #include #include using namespace std; class Component{public:       string m_strName;       Component(string strName

#include #include #include using namespace std; class Company{protected:       string m_strName;public:       Company(string strName)       {              m_strName = strName;

GOOD：将抽象部分与实现部分分离，使它们可以独立变化。　　　这里说的意思不是让抽象基类与具体类分离，而是现实系统可能有多角度分类，每一种分类都有可能变化，那么把这种多角度分离出来让它们独立变化，减少它们之间的耦合性，即如果继承不能实现“开放－封闭原则”的话，就应该考虑用桥接模式。如下例：让“手机”既可以按品牌分类也可以例：#include #include #includ

GOOD：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理为止。 例：#include #include #include using namespace std;//请求class Request{public:       string m_strContent;

GOOD：用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显示的相互引用，从而降低耦合；而且可以独立地改变它们之间的交互。例：#include #include #include using namespace std; class Colleague;//中介者类class Mediator{public:       virtual

GOOD：运用共享技术有效地支持大量细粒度的对象（对于C++来说就是共用一个内存块啦，对象指针指向同一个地方）。     如果一个应用程序使用了大量的对象，而这些对象造成了很大的存储开销就应该考虑使用。     还有就是对象的大多数状态可以外部状态，如果删除对象的外部状态，那么可以用较少的共享对象取代多组对象，此时可以考虑使用享元。例：#include #include

GOOD：通常当一个语言需要解释执行，并且你可以将该语言中的句子表示成为一个抽象的语法树时，可以使用解释器模式。例：#include #include #include using namespace std; class Context;class AbstractExpression{public:       virtual void Interp

GOOD：把不变的代码部分都转移到父类中，将可变的代码用virtual留到子类重写 例：#include#include #include using namespace std; class AbstractClass{public:      void Show()      {             cout我是"

GOOD：为子系统的一组接口提供一个一致的界面。使用户使用起来更加方便。例：#include#include using namespace std; class SubSysOne{public:       void MethodOne()       {              cout方法一"       }}; class S

GOOD：从一个对象再创建另外一个可定制的对象，而无需知道任何创建的细节。并能提高创建的性能。说白了就COPY技术，把一个对象完整的COPY出一份。 例：#include#include #include using namespace std; class Prototype //抽象基类{ private:       string m_strN

计算机软件工业是一个年轻的工业，它诞生于1950年，至今不过五十几年的历史。相比之下，建筑设计则可以追溯到几千年前埃及金字塔时代，甚至更早。因此，计算机软件设计师可以从建筑设计师那里学习到非常之多的经验和教训。计算机软件系统的设计和建筑设计有很明显的相似之处。　　如果读者到过纽约华尔街附近的话，会发现那里大量的古老雄伟的地标性建筑群中散布着一些超豪华住宅建筑，十分不和谐。其实这些建筑本是昂贵的办公

　建筑学的设计原则也应当成为软件系统设计的指导原则。　　第一种情况　　这也就是最为熟知的情况。客户端向第N层发出请求，而第N层不能独立完成请求，需要调用第N-1层所提供的服务，第N-1层同样需要他的下级，也就是N-2层所提供的服务。如此往复，直到第2层和第1层。　　第1层可以独立完成自己的任务，它将执行的结果返还给第2层。第2层得到第1层的结果之后，便能够继续完成自己的任务了，它会把执行的结果继续

定义定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法（Factory Method）使一个类的实例化延迟到其子类。也叫虚构造器（Virtual Constructor） 结构 理解1.      Product是工厂方法生产产品的抽象基类。2.      Creator是生产产品的工厂对象抽象基类。Creator提供创建虚方法即工厂方法Fact

GOOD：定义了一个创建一系列相关或相互依赖的接口，而无需指定它们的具体类。            用于交换产品系列，如ACCESS->SQL SERVER；            产品的具体类名被具体工厂的实现分离   例：#include #include #include  using namespace std; //用户抽象接口clas

主要用于创建对象。新添加类时，不会影响以前的系统代码。核心思想是用一个工厂来根据输入的条件产生不同的类，然后根据不同类的virtual函数得到不同的结果。　　GOOD:适用于不同情况创建不同的类时        BUG：客户端必须要知道基类和工厂类，耦合性差            （工厂类与基类为关联关系）//基类class COperation{pub

GOOD：定义了一种一对多的关系，让多个观察对象（公司员工）同时监听一个主题对象（秘书），主题对象状态发生变化时，会通知所有的观察者，使它们能够更新自己。 例：#include #include #include using namespace std; class Secretary;//看股票的同事类（观察对象，观察者）class StockObse

GOOD：提供一种方法顺序访问一个聚敛对象的各个元素，而又不暴露该对象的内部表示。为遍历不同的聚集结构提供如开始，下一个，是否结束，当前一项等统一接口。 #include using namespace std; class IntStack{public:    IntStack() { m_nTop = 0; }    virtual ~IntStack

GOOD：一、建立命令队列；二、可以将命令记入日志；三、接收请求的一方可以拒绝；四、添加一个新命令类不影响其它类；命令模式把请求一个操作的对象与知道怎么操行一个操作的对象分开例：#include #include #include using namespace std; //烤肉师傅class Barbucer{public:

动态地给一个对象添加一些额外的职责（不重要的功能，只是偶然一次要执行），就增加功能来说，装饰模式比生成子类更为灵活。建造过程不稳定，按正确的顺序串联起来进行控制。GOOD:当你向旧的类中添加新代码时，一般是为了添加核心职责或主要行为。而当需要加入的仅仅是一些特定情况下才会执行的特定的功能时（简单点就是不是核心应用的功能），就会增加类的复杂度。装饰模式就是把要添加的附加功能分别放在单独的类中

定义算法家族，分别封装起来，让它们之间可以互相替换，让算法变化，不会影响到用户      　　GOOD:适合类中的成员以方法为主，算法经常变动；简化了单元测试（因为每个算法都有自己的类，可以通过自己的接口单独测试。　　策略模式和简单工厂基本相同，但简单工厂模式只能解决对象创建问题，对于经常变动的算法应使用策略模式。　　BUG:客户端要做出判断 例//策略基类cl

GOOD：远程代理，可以隐藏一个对象在不同地址空间的事实　　　　　　　虚拟代理：通过代理来存放需要很长时间实例化的对象　　　　　　　安全代理：用来控制真实对象的访问权限　　　　　　　智能引用：当调用真实对象时，代理处理另外一些事 例：#include #include using namespace std;//定义接口class Interface

GOOD：适用于数据结构稳定的系统。它把数据结构和作用于数据结构上的操作分离开，使得操作集合     优点：新增加操作很容易，因为增加新操作就相当于增加一个访问者，访问者模式将有关的行为集中到一个访问者对象中 例：#include #include #include using namespace std; class Man;class Woman;/