“战略上藐视敌人，战术上重视敌人”
1936年12月，毛泽东在红军大学所作的《中国革命战争的战略问题》演说中指出：“我们的战略是‘以一当十’，我们的战术是‘以十当一’，这是 我们制胜敌人的根本法则之一。”“我们是以少胜多的--我们向整个中国统治者这样说。我们又是以多胜少的--我们向战场上作战的各个局部的敌人这样说。” 1948年1月18日，毛泽东在为中共中央起草的决议草案《关于目前党的政策中的几个重要问题》中又说：“当着我们正确地指出在全体上，在战略上，应当轻 视敌人的时候，却决不可在每一个局部上，在每一个具体问题上，也轻视敌人。”这些论述后来被概括为“战略上藐视敌人，战术上重视敌人”口号，成为毛泽东战 略和策略思想的集中表达。
问题就这样提出来了！一场战争的胜利的决定因素是多方面的，我们把问题集中到”全局“与”局部“两个方面，也就是本文将要重点要阐述的"战略"层面与"战 术"层面的各种手段。我们把问题聚焦在程序设计上，由于流程制定者以及管理者缺乏对软件开发过程中的多种技术手段的认识，一切都被机械地流程化或规范化， 而对整个程序设计过程中的”战略“与”战术“不够重视，导致在程序设计这场战争中不利或失利。
在软件工程中，强调三个组成部分，四项基本原则，七个基本原理，软件工程所要解决的应该是在软件开发过程中管理层面的战略问题，本文抛开这些技术问题，将问题集中在技术成面。
粗论模式
提到模式，首先脑子里面冒出来的 GOF(四人帮)的23种设计模式(Disgin Pattern)，这23种设计模式被我称为战术模式---因为这种模式只能在相对较小的局部范围内生效，没有办法处理软件产品全局统一层面的问题，
是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。。另外有一个词Framework(框架），我把这个词理解为战略模式---因为这种模式强调
整个或部分系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法;另一种定义认为，框架是可被应用开发者定制的应用骨架。前者是从应用方面而后者是从目的方面给出的定义。
毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。
GoF的“设计模式”是第一次将设计模式提升到理论高度，并将之规范化，提出了23种基本设计模式，自此，在可复用面向对象软件的发展过程中，新的大量的设计模式不断出现。
GoF:（Gang of Four，GOF设计模式）---四人组
Design Patterns: Elements of Reusable Object-Oriented Software（即《设计模式》 一书），由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 合著（Addison-Wesley，1995）。这几位作者常被称为“四人组（Gang of Four）”，而这本书也就被称为“四人组（或 GoF）”书。
在《设计模式》这本书的最大部分是一个目录，该目录列举并描述了 23 种设计模式。
GOF的设计模式是一座"桥"
就Java语言体系来说，GOF的设计模式是Java基础知识和J2EE框架知识之间一座隐性的"桥"。
会Java的人越来越多，但是一直徘徊在语言层次的程序员不在少数，真正掌握Java中接口或抽象类的应用不是很多，大家经常以那些技术只适合大型项目为 由，避开或忽略它们，实际中，Java的接口或抽象类是真正体现Java思想的核心所在，这些你都将在GoF的设计模式里领略到它们变幻无穷的魔力。
GoF的设计模式表面上好象也是一种具体的"技术"，而且新的设计模式不断在出现，设计模式自有其自己的发展轨道，而这些好象和J2EE .Net等技术也无关！
实际上，GoF的设计模式并不是一种具体"技术",它讲述的是思想，它不仅仅展示了接口或抽象类在实际 案例中的灵活应用和智慧，让你能够真正掌握接口或抽象类的应用，从而在原来的Java语言基础上跃进一步，更重要的是，GoF的设计模式反复向你强调一个 宗旨：要让你的程序尽可能的可重用。
这其实在向一个极限挑战：软件需求变幻无穷，计划没有变化快，但是我们还是要寻找出不变的东西，并将它和变化的东西分离开来，这需要非常的智慧和经验。
而GoF的设计模式是在这方面开始探索的一块里程碑。
J2EE等属于一种框架软件，什么是框架软件？它不同于我们以前接触的Java API等，那些属于Toolkist(工具箱)，它不再被动的被使用，被调用，而是深刻的介入到一个领域中去，J2EE等框架软件设计的目的是将一个领域中不变的东西先定义好，比如整体结构和一些主要职责(如数据库操作 事务跟踪 安全等)，剩余的就是变化的东西，针对这个领域中具体应用产生的具体不同的变化需求，而这些变化东西就是J2EE程序员所要做的。
由此可见，设计模式和J2EE在思想和动机上是一脉相承，只不过
1.设计模式更抽象，J2EE是具体的产品代码，我们可以接触到，而设计模式在对每个应用时才会产生具体代码。
2.设计模式是比J2EE等框架软件更小的体系结构，J2EE中许多具体程序都是应用设计模式来完成的，当你深入到J2EE的内部代码研究时，这点尤其明显，因此，如果你不具备设计模式的基础知识(GoF的设计模式)，你很难快速的理解J2EE。不能理解J2EE,如何能灵活应用？
3.J2EE只是适合企业计算应用的框架软件，但是GoF的设计模式几乎可以用于任何应用！因此GoF的设计模式应该是J2EE的重要理论基础之一。
所以说，GoF的设计模式是Java基础知识和J2EE框架知识之间一座隐性的"桥"。为什么说隐性的？
GOF设计模式是一座隐性的"桥"
因为很多人没有注意到这点，学完Java基础语言就直接去学J2EE,有的甚至鸭子赶架，直接使用起Weblogic等具体J2EE软件，一段时间下来， 发现不过如此，挺简单好用，但是你真正理解J2EE了吗？你在具体案例中的应用是否也是在延伸J2EE的思想？
如果你不能很好的延伸J2EE的思想，那你岂非是大炮轰蚊子，认识到J2EE不是适合所有场合的人至少是明智的，但我们更需要将J2EE用对地方，那么只 有理解J2EE此类框架软件的精髓，那么你才能真正灵活应用Java解决你的问题，甚至构架出你自己企业的框架来。(我们不能总是使用别人设定好的框架， 为什么不能有我们自己的框架？)
因此，首先你必须掌握GoF的设计模式。虽然它是隐性，但不是可以越过的。
设计模式和框架
现在，可复用面向对象软件（面向对象以不再限制于C++等面向对象的语言，我们可以抽象到C等任何编程语言，只要在设计的把我好设计思路）系统现在一般划分为三大类：应用程序、工具箱和框架(Framework),我们平时开发的具体软件都是应用程序；GLIBC的API属于工具箱;而框架是构成一类特定软件可复用设计的一组相互协作的类。EJB（EnterpriseJavaBeans）是Java应用于企业计算的框架.
框架通常定义了应用体系的整体结构类和对象的关系等等设计参数，以便于具体应用实现者能集中精力于应用本身的特定细节。框架主要记录软件应用中共同的设计决策，框架强调设计复用，因此框架设计中必然要使用设计模式.
另外，设计模式有助于对框架结构的理解，成熟的框架通常使用了多种设计模式,如果你熟悉这些设计模式，毫无疑问，你将迅速掌握框架的结构，我们一般开发者如果突然接触EJB J2EE .Net ACE等框架，会觉得特别难学，难掌握，那么转而先掌握设计模式，无疑是给了你剖析EJB、J2EE或ACE等系统的一把利器。
设计模式的原则
近年来，大家都开始注意设计模式。那么，到底我们为什么要用设计模式呢？这么多设计模式为什么要这么设计呢？说实话，到现在为之我还真没搞清楚。就是看大家一口一个"Design pattern"，心就有点发虚。于是就深研了"四人帮"的设计模式，结果看得似懂非懂:看得时候好像是懂了，过一会就忘了。可能是我比较"愚钝"吧:))最近一年，由于编程工作繁重，接触了多种框架技术（包括ACE,BOOST,J2EE,Apache,WTL/MFC,libevent等）终于有了点感悟。"独乐不如众乐"，与大家分享一下，还望指教!
为什么要提倡"Design Pattern"呢？根本原因是为了代码复用，增加可维护性。那么怎么才能实现代码复用呢？OO界有前辈的几个原则："开－闭"原则(Open Closed Principal)、里氏代换原则、合成复用原则。设计模式就是实现了这些原则，从而达到了代码复用、增加可维护性的目的，抱着学习的态度，我们在看看这些原则。
1、"开－闭"原则
此原则是由"Bertrand Meyer"提出的。原文是："Software entities should be open for extension,but closed for modification"。就是说模块应对扩展开放，而对修改关闭。模块应尽量在不修改原(是"原"，指原来的代码)代码的情况下进行扩展。工厂模式以及抽象工厂模式，代理模式，装饰模式都可以实现着这一原则
2、里氏代换原则
里氏代换原则是由"Barbara Liskov"提出的。如果调用的是父类的话，那么换成子类也完全可以运行。在面向对象的语言中如C++或Java中可以通过集成来实现这一原则，在C语言中我们通过通过结构封装以及结构嵌套来实现这一模式，不过设计起来难道会比面向对象与语言大得多。可以说：里氏代换原则是继承复用的一个基础。
3、合成复用原则
就是说要少用继承，多用合成关系来实现。我曾经这样写过程序：有几个类要与数据库打交道，就写了一个数据库操作的类，然后别的跟数据库打交道的类都继承这个。结果后来，我修改了数据库操作类的一个方法，各个类都需要改动。"牵一发而动全身"!面向对象是要把波动限制在尽量小的范围。在Java，C#中，应尽量针对Interface编程，而非实现类。这样，更换子类不会影响调用它方法的代码。要让各个类尽可能少的跟别人联系，"不要与陌生人说话"。这样，城门失火，才不至于殃及池鱼。扩展性和维护性才能提高。在C++高，不考虑性能印因素外可以采用虚类及纯虚函数来实现类是的接口概念。
理解了这些原则，再看设计模式，只是在具体问题上怎么实现这些原则而已。张无忌学太极拳，忘记了所有招式，打倒了"玄幂二老"，所谓"心中无招"。设计模式可谓招数，如果先学通了各种模式，又忘掉了所有模式而随心所欲，可谓OO之最高境界。呵呵，搞笑，搞笑！
4 依赖倒转原则
抽象不应该依赖与细节，细节应当依赖与抽象。要针对接口编程，而不是针对实现编程。传递参数，或者在组合聚合关系中，尽量引用层次高的类。主要是在构造对象时可以动态的创建各种具体对象，当然如果一些具体类比较稳定，就不必在弄一个抽象类做它的父类，这样有画舌添足的感觉。在C语言的世界里，一般是针对实现而非接口编程，所以C语言实现的产品维护起来要比面向接口实现的产品困难的多。在C语言的世界里，函数要象女人的裙子一样越短越好，功能要单一，代码页不能太多，看上一眼就明白这个函数时干什么的了！只有这样才能够复杂问题简单化，降低系统复杂度。
5 接口隔离原则
定制服务的例子，每一个接口应该是一种角色，不多不少，不干不该干的事，该干的事都要干。不能图省事，破坏这条原则的后果将是，接口函数不清，内部实现混乱，维护工作繁重。
6 抽象类
抽象类不会有实例，一般作为父类为子类继承，一般包含这个系的共同属性和方法。注意：好的继承关系中，只有叶节点是具体类，其他节点应该都是抽象类，也就是说具体类是不被继承的。将尽可能多的共同代码放到抽象类中。在C语言实现中，每个功能都应该独立有一个函数来实现，尽量做到复用。
7 迪米特法则
最少知识原则。实现内部内部的知识是自主的、完毕的，不依赖于任何外部的逻辑或功能。可以理解为不要和陌生人说话。
再论模式
一个模式的四个基本要素
设计模式使人们可以更加简单方便地复用成功的设计和体系结构。将已证实的技术表述成设计模式也会使新系统开发者更加容易理解其设计思路。
1. 模式名称（pattern name）
一个助记名，它用一两个词来描述模式的问题、解决方案和效果。命名一个新的模式增加了我们的设计词汇。设计模式允许我们在较高的抽象层次上进行设计。基于一个模式词汇表，交流之间、讨论模式或编写文档时使用它们。模式名可以帮助我们思考，便于我们与其他人交流设计思想及设计结果。找到恰当的模式名也是我们设计模式编目工作的难点之一。
2. 问题(problem)
描述了应该在何时使用模式。它解释了设计问题和问题存在的前因后果，它可能描述了特定的设计问题，如怎样用对象表示算法等。也可能描述了导致不灵活设计的类或对象结构。有时候，问题部分会包括使用模式必须满足的一系列先决条件。
3. 解决方案(solution)
描述了设计的组成成分，它们之间的相互关系及各自的职责和协作方式。因为模式就像一个模板，可应用于多种不同场合，所以解决方案并不描述一个特定而具体的 设计或实现，而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合（类或对象组合）来解决这个问题。
4. 效果(consequences)
描述了模式应用的效果及使用模式应权衡的问题。尽管我们描述设计决策时，并不总提到模式效果，但它们对于评价设计选择和理解使用模式的代价及好处具有重要意义。软件效果大多关注对时间和空间的衡量，它们也表述了语言和实现问题。因为复用是面向对象设计的要素之一，所以模式效果包括它对系统的灵活性、扩充性或可移植性的影响，显式地列出这些效果对理解和评价这些模式很有帮助。
23种基本的设计模式
创建型模式
1.Abstract Factory（抽象工厂）： 提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
2.Builder（建造模式）： 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
3.Factory Method（工厂方法模式）： 定义一个用于创建对象的接口，让子类决定将哪一个类实例化。Factory Method使一个类的实例化延迟到其子类。
4.Prototype（原形模式）： 用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象。
5.Singleton（单例模式）： 保证一个类仅有一个实例，并提供一个访问它的全局访问点。
结构型模式
6.Adapter（适配器模式）： 将一个类的接口转换成客户希望的另外一个接口。A d a p t e r模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
7.Bridge（桥梁模式）： 将抽象部分与它的实现部分分离，使它们都可以独立地变化。
8.Composite（合成模式）： 将对象组合成树形结构以表示“部分-整体”的层次结构。它使得客户对单个对象和复合对象的使用具有一致性。
9.Decorator(装饰模式)： 动态地给一个对象添加一些额外的职责。就扩展功能而言， 它比生成子类方式更为灵活。
10.Facade（门面模式）： 为子系统中的一组接口提供一个一致的界面， F a c a d e模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
11.Flyweight（享元模式）： 运用共享技术有效地支持大量细粒度的对象。
12.Proxy（代理）： 为其他对象提供一个代理以控制对这个对象的访问。
行为模式13.Chain of Responsibility（责任链模式）： 为解除请求的发送者和接收者之间耦合，而使多个对象都有机会处理这个请求。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它。
14.Command（命令模式）： 将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可取消的操作。
15.Interpreter（解释器模式）： 给定一个语言, 定义它的文法的一种表示，并定义一个解释器, 该解释器使用该表示来解释语言中的句子。
16.Iterator（迭代子模式）： 提供一种方法顺序访问一个聚合对象中各个元素, 而又不需暴露该对象的内部表示。
17.Mediator（调停者模式）： 用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
18.Memento（备忘录模式）： 在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到保存的状态。
19.Observer（观察者模式）： 定义对象间的一种一对多的依赖关系,以便当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并自动刷新。
20.State（状态模式）： 允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它所属的类。
21.Strategy（策略模式）： 定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法的变化可独立于使用它的客户。
22.Template Method（模板方法模式）： 定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
23. Visitor（访问者模式）： 表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
深入模式
名称 Factory Method
意图 定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method 使一个类的实例化延迟到其子类。
适用性 当一个类不知道它所必须创建的对象的类的时候。
当一个类希望由它的子类来指定它所创建的对象的时候。
当类将创建对象的职责委托给多个帮助子类中的某一个，并且你希望将哪一个帮助子类是代理者这一信息局部化的时候。
说明 核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。
名称 Abstract Factory
意图 提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
适用性 一个系统要独立于它的产品的创建、组合和表示时。
一个系统要由多个产品系列中的一个来配置时。
当你要强调一系列相关的产品对象的设计以便进行联合使用时。
当你提供一个产品类库，而只想显示它们的接口而不是实现时。
说明 客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。
名称 Builder
意图 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
适用性 当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。
当构造过程必须允许被构造的对象有不同的表示时。
说明: 将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。
名称 Prototype
意图 用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
适用性 当要实例化的类是在运行时刻指定时，例如，通过动态装载；或者
为了避免创建一个与产品类层次平行的工厂类层次时；或者
当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些。
说明 通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类，产品类不需要非得有任何事先确定的等级结构，原始模型模式适用于任何的等级结构。缺点是每一个类都必须配备一个克隆方法。
名称 Singleton
意图 保证一个类仅有一个实例，并提供一个访问它的全局访问点。
适用性 当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时。
当这个唯一实例应该是通过子类化可扩展的，并且客户应该无需更改代码就能使用一个扩展的实例时。
说明 单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。
名称 Adapter
意图 将一个类的接口转换成客户希望的另外一个接口。A d a p t e r 模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
适用性 你想使用一个已经存在的类，而它的接口不符合你的需求。
你想创建一个可以复用的类，该类可以与其他不相关的类或不可预见的类（即那些接口可能不一定兼容的类）协同工作。
（仅适用于对象A d a p t e r ）你想使用一些已经存在的子类，但是不可能对每一个都进行子类化以匹配它们的接口。对象适配器可以适配它的父类接口。
说明 把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个合适的实例给客户端。
名称 Bridge
意图 将抽象部分与它的实现部分分离，使它们都可以独立地变化。
适用性 你不希望在抽象和它的实现部分之间有一个固定的绑定关系。例如这种情况可能是因为，在程序运行时刻实现部分应可以被选择或者切换。
类的抽象以及它的实现都应该可以通过生成子类的方法加以扩充。这时B r i d g e 模式使你可以对不同的抽象接口和实现部分进行组合，并分别对它们进行扩充。
对一个抽象的实现部分的修改应对客户不产生影响，即客户的代码不必重新编译。
（C + +）你想对客户完全隐藏抽象的实现部分。在C + +中，类的表示在类接口中是可见的。
有许多类要生成。这样一种类层次结构说明你必须将一个对象分解成两个部分。R u m b a u g h 称这种类层次结构为“嵌套的普化”（nested generalizations ）。
你想在多个对象间共享实现（可能使用引用计数），但同时要求客户并不知道这一点。一个简单的例子便是C o p l i e n 的S t r i n g 类[ C o p 9 2 ]，在这个类中多个对象可以共享同一个字符串表示（S t r i n g R e p ）。
说明 将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以独立的变化。
名称 Composite
意图 将对象组合成树形结构以表示“部分-整体”的层次结构。C o m p o s i t e 使得用户对单个对象和组合对象的使用具有一致性。
适用性 你想表示对象的部分-整体层次结构。
你希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象。
说明 合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模式就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。
名称 Decorator
意图 动态地给一个对象添加一些额外的职责。就增加功能来说，D e c o r a t o r 模式相比生成子类更为灵活。
适用性 在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。
处理那些可以撤消的职责。
当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。
另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。
说明 装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案，提供比继承更多的灵活性。动态给一个对象增加功能，这些功能可以再动态的撤消。增加由一些基本功能的排列组合而产生的非常大量的功能。
名称 Facade
意图 为子系统中的一组接口提供一个一致的界面，F a c a d e 模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
适用性 当你要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性，也更容易对子系统进行定制，但这也给那些不需要定制子系统的用户带来一些使用上的困难。F a c a d e 可以提供一个简单的缺省视图，这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过f a c a d e 层。
客户程序与抽象类的实现部分之间存在着很大的依赖性。引入f a c a d e 将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。
当你需要构建一个层次结构的子系统时，使用f a c a d e 模式定义子系统中每层的入口点。如果子系统之间是相互依赖的，你可以让它们仅通过f a c a d e 进行通讯，从而简化了它们之间的依赖关系。
说明 外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。每一个子系统只有一个门面类，而且此门面类只有一个实例，也就是说它是一个单例模式。但整个系统可以有多个门面类。
名称 Flyweight
意图 运用共享技术有效地支持大量细粒度的对象。
适用性 一个应用程序使用了大量的对象。
完全由于使用大量的对象，造成很大的存储开销。
对象的大多数状态都可变为外部状态。
如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象。
应用程序不依赖于对象标识。由于F l y w e i g h t 对象可以被共享，对于概念上明显有别的对象，标识测试将返回真值。
说明 FLYWEIGHT在拳击比赛中指最轻量级。享元模式以共享的方式高效的支持大量的细粒度对 象。享元模式能做到共享的关键是区分内蕴状态和外蕴状态。内蕴状态存储在享元内部，不会随环境的改变而有所不同。外蕴状态是随环境的改变而改变的。外蕴状 态不能影响内蕴状态，它们是相互独立的。将可以共享的状态和不可以共享的状态从常规类中区分开来，将不可以共享的状态从类里剔除出去。客户端不可以直接创 建被共享的对象，而应当使用一个工厂对象负责创建被共享的对象。享元模式大幅度的降低内存中对象的数量。
名称 Proxy
意图 为其他对象提供一种代理以控制对这个对象的访问。
适用性 在需要用比较通用和复杂的对象指针代替简单的指针的时候，使用P r o x y 模式。下面是一 些可以使用P r o x y 模式常见情况：
1) 远程代理（Remote Proxy ）为一个对象在不同的地址空间提供局部代表。 NEXTSTEP[Add94] 使用N X P r o x y 类实现了这一目的。Coplien[Cop92] 称这种代理为“大使” （A m b a s s a d o r ）。
2 )虚代理（Virtual Proxy ）根据需要创建开销很大的对象。在动机一节描述的I m a g e P r o x y 就是这样一种代理的例子。
3) 保护代理（Protection Proxy ）控制对原始对象的访问。保护代理用于对象应该有不同 的访问权限的时候。例如，在C h o i c e s 操作系统[ C I R M 9 3 ]中K e m e l P r o x i e s 为操作系统对象提供 了访问保护。
4 )智能指引（Smart Reference ）取代了简单的指针，它在访问对象时执行一些附加操作。 它的典型用途包括：
对指向实际对象的引用计数，这样当该对象没有引用时，可以自动释放它(也称为S m a r tP o i n t e r s[ E d e 9 2 ] )。
当第一次引用一个持久对象时，将它装入内存。
在访问一个实际对象前，检查是否已经锁定了它，以确保其他对象不能改变它。
说明 代理模式给某一个对象提供一个代理对象，并由代理对象控制对源对象的引用。代理就是一个人或一 个机构代表另一个人或者一个机构采取行动。某些情况下，客户不想或者不能够直接引用一个对象，代理对象可以在客户和目标对象直接起到中介的作用。客户端分 辨不出代理主题对象与真实主题对象。代理模式可以并不知道真正的被代理对象，而仅仅持有一个被代理对象的接口，这时候代理对象不能够创建被代理对象，被代 理对象必须有系统的其他角色代为创建并传入。
名称 Chain of Responsibility
意图 使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
适用性 有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定。
你想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。
可处理一个请求的对象集合应被动态指定。
说明 在责任链模式中，很多对象由每一个对象对其下家的引用而接起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。客户并不知道链上的哪一个对象最终处理这个请求，系统可以在不影 响客户端的情况下动态的重新组织链和分配责任。处理者有两个选择：承担责任或者把责任推给下家。一个请求可以最终不被任何接收端对象所接受。
名称 Command
意图 将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。
适用性 抽象出待执行的动作以参数化某对象。你可用过程语言中的回调（c a l l b a c k ）函数表达这种参数化机制。
所谓回调函数是指函数先在某处注册，而它将在稍后某个需要的时候被调用。C o m m a n d 模式是回调机制的一个面向对象的替代品。
在不同的时刻指定、排列和执行请求。一个C o m m a n d 对象可以有一个与初始请求无关的生存期。如果一个请求的接收者可用一种与地址空间无关的方式表达，那么就可将负责该请求的命令对象传送给另一个不同的进程并在那儿实现该请求。支持取消操作。C o m m a n d 的E x c u t e 操作可在实施操作前将状态存储起来，在取消操作时这个状态用来消除该操作的影响。C o m m a n d 接口必须添加一个U n e x e c u t e 操作，该操作取消上一次E x e c u t e 调用的效果。执行的命令被存储在一个历史列表中。可通过向后和向前遍历这一列表并分别调用U n e x e c u t e 和E x e c u t e 来实现重数不限的“取消”和“重做”。支持修改日志，这样当系统崩溃时，这些修改可以被重做一遍。在C o m m a n d 接口中添加装载操作和存储操作，可以用来保持变动的一个一致的修改日志。从崩溃中恢复的过程包括从磁盘中重新读入记录下来的命令并用E x e c u t e 操作重新执行它们。用构建在原语操作上的高层操作构造一个系统。这样一种结构在支持事务( t r a n s a c t i o n )的信息系统中很常见。一个事务封装了对数据的一组变动。C o m m a n d 模式提供了对事务进行建模的方法。C o m m a n d 有一个公共的接口，使得你可以用同一种方式调用所有的事务。同时使用该模式也易于添加新事务以扩展系统。
说明 命令模式把一个请求或者操作封装到一个对象中。命令模式把发出命令的责任和执行命令的责任分割 开，委派给不同的对象。命令模式允许请求的一方和发送的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操 作是否执行，何时被执行以及是怎么被执行的。系统支持命令的撤消。
名称 Interpreter
意图 给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
适用性 当有一个语言需要解释执行, 并且你可将该语言中的句子表示为一个抽象语法树时，可使用解释器模式。而当存在以下情况时该模式效果最好：
该文法简单对于复杂的文法, 文法的类层次变得庞大而无法管理。此时语法分析程序生成器这样的工具是更好的选择。它们无需构建抽象语法树即可解释表达式, 这样可以节省空间而且还可能节省时间。
效率不是一个关键问题最高效的解释器通常不是通过直接解释语法分析树实现的, 而是首先将它们转换成另一种形式。例如，正则表达式通常被转换成状态机。但即使在这种情况下, 转换器仍可用解释器模式实现, 该模式仍是有用的。
说明 给定一个语言后，解释器模式可以定义出其文法的一种表示，并同时提供一个解释器。客户端可以使 用这个解释器来解释这个语言中的句子。解释器模式将描述怎样在有了一个简单的文法后，使用模式设计解释这些语句。在解释器模式里面提到的语言是指任何解释 器对象能够解释的任何组合。在解释器模式中需要定义一个代表文法的命令类的等级结构，也就是一系列的组合规则。每一个命令对象都有一个解释方法，代表对命 令对象的解释。命令对象的等级结构中的对象的任何排列组合都是一个语言。
名称 Iterator
意图 提供一种方法顺序访问一个聚合对象中各个元素, 而又不需暴露该对象的内部表示。
适用性 访问一个聚合对象的内容而无需暴露它的内部表示。
支持对聚合对象的多种遍历。
为遍历不同的聚合结构提供一个统一的接口(即, 支持多态迭代)。
说明 迭代子模式可以顺序访问一个聚集中的元素而不必暴露聚集的内部表象。多个对象聚在一起形成的总 体称之为聚集，聚集对象是能够包容一组对象的容器对象。迭代子模式将迭代逻辑封装到一个独立的子对象中，从而与聚集本身隔开。迭代子模式简化了聚集的界 面。每一个聚集对象都可以有一个或一个以上的迭代子对象，每一个迭代子的迭代状态可以是彼此独立的。迭代算法可以独立于聚集角色变化。
名称 Mediator
意图 用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
适用性 一组对象以定义良好但是复杂的方式进行通信。产生的相互依赖关系结构混乱且难以理解。
一个对象引用其他很多对象并且直接与这些对象通信,导致难以复用该对象。
想定制一个分布在多个类中的行为，而又不想生成太多的子类。
说明 调停者模式包装了一系列对象相互作用的方式，使得这些对象不必相互明显作用。从而使他们可以松 散偶合。当某些对象之间的作用发生改变时，不会立即影响其他的一些对象之间的作用。保证这些作用可以彼此独立的变化。调停者模式将多对多的相互作用转化为 一对多的相互作用。调停者模式将对象的行为和协作抽象化，把对象在小尺度的行为上与其他对象的相互作用分开处理。
名称 Memento
意图 在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。
适用性 必须保存一个对象在某一个时刻的(部分)状态, 这样以后需要时它才能恢复到先前的状态。
如果一个用接口来让其它对象直接得到这些状态，将会暴露对象的实现细节并破坏对象的封装性。
说明 备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模式的用意是在不破坏封装的条件下，将一个对象的状态捉住，并外部化，存储起来，从而可以在将来合适的时候把这个对象还原到存储起来的状态。
名称 Observer
意图 定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新。
适用性 当一个抽象模型有两个方面, 其中一个方面依赖于另一方面。将这二者封装在独立的对象中以使它们可以各自独立地改变和复用。
当对一个对象的改变需要同时改变其它对象, 而不知道具体有多少对象有待改变。
当一个对象必须通知其它对象，而它又不能假定其它对象是谁。换言之, 你不希望这些对象是紧密耦合的。
说明 观察者模式定义了一种一队多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，使他们能够自动更新自己。
名称 State
意图 允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。
适用性 一个对象的行为取决于它的状态, 并且它必须在运行时刻根据状态改变它的行为。
一 个操作中含有庞大的多分支的条件语句，且这些分支依赖于该对象的状态。这个状态通常用一个或多个枚举常量表示。通常, 有多个操作包含这一相同的条件结构。S t a t e模式将每一个条件分支放入一个独立的类中。这使得你可以根据对象自身的情况将对象的状态作为一个对象，这一对象可以不依赖于其他对象而独立变化。
说明 状态模式允许一个对象在其内部状态改变的时候改变行为。这个对象看上去象是改变了它的类一样。 状态模式把所研究的对象的行为包装在不同的状态对象里，每一个状态对象都属于一个抽象状态类的一个子类。状态模式的意图是让一个对象在其内部状态改变的时 候，其行为也随之改变。状态模式需要对每一个系统可能取得的状态创立一个状态类的子类。当系统的状态变化时，系统便改变所选的子类。
名称 Strategy
意图 定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。
适用性 许多相关的类仅仅是行为有异。“策略”提供了一种用多个行为中的一个行为来配置一个类的方法。
需要使用一个算法的不同变体。例如，你可能会定义一些反映不同的空间/时间权衡的算法。当这些变体实现为一个算法的类层次时[ H O 8 7 ] ,可以使用策略模式。
算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构。
一个类定义了多种行为, 并且这些行为在这个类的操作中以多个条件语句的形式出现。将相关的条件分支移入它们各自的S t r a t e g y 类中以代替这些条件语句。
说明 策略模式针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替 换。策略模式使得算法可以在不影响到客户端的情况下发生变化。策略模式把行为和环境分开。环境类负责维持和查询行为类，各种算法在具体的策略类中提供。由 于算法和环境独立开来，算法的增减，修改都不会影响到环境和客户端。
名称 Template Method
意图 定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Te m p l a t e M e t h o d 使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
适用性 一次性实现一个算法的不变的部分，并将可变的行为留给子类来实现。
各子类中公共的行为应被提取出来并集中到一个公共父类中以避免代码重复。这是O p d y k e 和J o h n s o n 所描述过的“重分解以一般化”的一个很好的例子[ O J 9 3 ]。首先识别现有代码中的不同之处，并且将不同之处分离为新的操作。最后，用一个调用这些新的操作的模板方法来替换这些不同的代码。
控制子类扩展。模板方法只在特定点调用“h o o k ”操作（参见效果一节），这样就只允许在这些点进行扩展。
说明 模板方法模式准备一个抽象类，将部分逻辑以具体方法以及具体构造子的形式实现，然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法，从而对剩余的逻辑有不同的实现。先制定一个顶级逻辑框架，而将逻辑的细节留给具体的子类去实现。
名称 Visitor
意图 表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
适用性 一个对象结构包含很多类对象，它们有不同的接口，而你想对这些对象实施一些依赖于其具体类的操作。
需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而你想避免让这些操作“污染”这些对象的类。Vi s i t o r 使得你可以将相关的操作集中起来定义在一个类中。当该对象结构被很多应用共享时，用Vi s i t o r 模式让每个应用仅包含需要用到的操作。
定义对象结构的类很少改变，但经常需要在此结构上定义新的操作。改变对象结构类需要重定义对所有访问者的接口，这可能需要很大的代价。如果对象结构类经常改变，那么可能还是在这些类中定义这些操作较好。
说明 访问者模式的目的是封装一些施加于某种数据结构元素之上的操作。一旦这些操作需要修改的话，接 受这个操作的数据结构可以保持不变。访问者模式适用于数据结构相对未定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对 自由的演化。访问者模式使得增加新的操作变的很容易，就是增加一个新的访问者类。访问者模式将有关的行为集中到一个访问者对象中，而不是分散到一个个的节 点类中。当使用访问者模式时，要将尽可能多的对象浏览逻辑放在访问者类中，而不是放到它的子类中。访问者模式可以跨过几个类的等级结构访问属于不同的等级 结构的成员类。
成功采用设计模式的三个步骤
如何把设计模式的采用和日益临近的最后期限、紧缩的预算和很多公司现有的有限团队资源相结合？以下是成功制订设计模式的三个步骤。
强大的通信和培训 许多机构拥有领先技术，可能正式通过了设计师论坛的论证或者非正式的公认专家。这些领先厂商将推广设计模式采用中的开放通信，并将培训开发具体设计模式的团队。通信应当跨开发团队和 项目以便预先防止采用竖井和多种惟一的实现（谨记每个Developer/Project AntiPattern的实现）。培训可以采用正式的internal lunch-and-learns、正式的internal class或者派一些员工参加外部培训。这些培训方式将促进正确的设计模式应用程序。如果仅有极少的观众能够参加培训，最佳的候选人是那些感觉适合在回来 后能够培训其同事的人。
设计模式采用指导 设计模式可用于使项目受益， 但是他们也可能因为误用而对应用程序造成损害。应当鼓励采用他们，但是对其的采用应当受到审阅和验证。设计模式可以包含在设计和开发过程中。在任何一种情 况中，设计模式的使用应当由审阅者确认和验证。在审阅过程中还可能会遇到这样的情况，额外的设计模式不适用于最初包括的地方。即使环境中没有进行正式的审 阅，这一步骤也可以通过同事审阅或者团队讨论来完成。这一步骤中的审阅者要么是主要团队的成员，要么与他们建立开放通信。指导采用对于broad exposure类别的设计模式非常关键。这些设计模式具有很多相关的风险，因为他们将创建依赖性。这些依赖性可能在一些对象类中，例如，只工作在更加广泛的DAO设计模式实现范围中的数据访问对象（DAO）、或者跨应用程序边界（如使用Value Object设计模式在应用程序和应用程序层之间传输数据）。这些设计模式也可以由项目中的其他人或者不同项目的人实现，而且实现应当重新使用，不同于创建另一种独特的实现。重用实现,不只是设计模式 只要在创建自己的设 计模式实现中有一定的满足，团队和公司就可以在重用发生在代码层时，而不是设计创意层时获得更多益处。使企业获益的最初设计模式是改进的实现。但是，真正 的目标是重用实现。重用实现将导致：a)其他可重用的类（取决于公共实现）；b)缩短开发时间和降低成本；c)缩短维护时间和降低成本；d)在应用程序之 间和内部轻松集成。这种重用对broad exposure设计模式非常重要（有时是基本的）。这些设计模式创建了外部依赖性（集成将从公共实现中受益）或者产生全部的自定义类库（如果有公共基础 将可重用）。isolated use设计模式也可以从重用中获益，但是如果他们是根据具体情况定制的，他们就非常难以重用。有时您可能会问 自己：“如果重用比较好，为什么设计模式和可以重用的实现不可以一同应用呢？”在我们讨论设计模式如何使更多读者获益的时候才会讨论这个问题。如果可能， 如果已经预定义了实现，那么达到广泛适用性这个目标就会非常困难。然而，一旦设计模式被应用到特殊的问题域或者技术基础设施中，那么就可以重用在该环境中 产生的实现。
架构中的设计模式 这看起来像是一件可怕的任务，需要掌握设计模式如何应用在实际情况中，如何构建优质的实现，以及如何促进重用实现。完成该任务的方法之一就是在环境中引 入应用程序架构。应用程序架构提供了应用程序需要的结构，从而使开发团队可以关注应用程序的域逻辑。这包含了已实现的设计模式。除了重用设计模式概念或者 单个实现之外，可以在多个项目和应用程序之间重用架构。这种共享的公共实现确保了兼容性，并为开发和维护多种不同的实现提供了一种低成本替代方案。兼容性 提供了重新使用需要的技术基础。没有足够的篇幅在这里深入讨论架构的其他重要品质，如运行时监测和管理、可配置应用程序逻辑和适应性行为等。您可以从 Carnegie Mellon Software Engineering Institute (www.sei.cmu.edu/ata/ata_init.html) 中学习到更多有关架构的知识。
粗论框架
可以说，一个框架是一个可复用的设计构件，它规定了应用的体系结构，阐明了整个设计、协作构件之间的依赖关系、责任分配和控制流程，表现为一组抽象类以及其实例之间协作的方法，它为构件复用提供了上下文(Context)关系。因此构件库的大规模重用也需要框架。
构件领域框架方法在很大程度上借鉴了硬件技术发展的成就，它是构件技术、软件体系结构研究和应用软件开发三者发展结合的产物。在很多情况下，框架通常以构件库的形式出现，但构件库只是框架的一个重要部分。框架的关键还在于框架内对象间的交互模式和控制流模式。
框架比构件可定制性强。在某种程度上，将构件和框架看成两个不同但彼此协作的技术或许更好。框架为构件提供重用的环境，为构件处理错误、交换数据及激活操作提供了标准的方法。
应用框架的概念也很简单。它并不是包含构件应用程序的 小片程序，而是实现了某应用领域通用完备功能（除去特殊应用的部分）的底层服务。使用这种框架的编程人员可以在一个通用功能已经实现的基础上开始具体的系 统开发。框架提供了所有应用期望的默认行为的类集合。具体的应用通过重写子类(该子类属于框架的默认行为)或组装对象来支持应用专用的行为。
应用框架强调的是软件的设计重用性和系统的可扩充性,以缩短大型应用软件系统的开发周期，提高开发质量。与传统的基于类库的面向对象重用技术比较，应用框架更注重于面向专业领域的软件重用。应用框架具有领域相关性，构件根据框架进行复合而生成可运行的系统。框架的粒度越大，其中包含的领域知识就更加完整。
框架，即framework。其实就是某种应用的半成品，就是一组组件，供你选用完成你自己的系统。简单说就是使用别人搭好的舞台，你来做表演。而且，框架一般是成熟的，不断升级的软件。
框架的概念最早起源于Smalltalk环境，其中最著名的框架是Smalltalk 80的用户界面框架MVC(Model -View-Controller)。随着用户界面框架Interviews [Linton 89]和ET++ [Weinand 89] 的开发和发布，框架研究越来越受到研究人员的重视。虽然框架研究最初起源于用户界面领域，但它还被成功地应用到其他领域中，如操作系统 [Russo 90]、火警系统 [Molin 96a，Molin 96b] 等。Taligent公司于1992年成立后，框架研究受到了广泛的重视。该公司计划基于框架来开发一个完整的面向对象操作系统。另外，该公司还发布了一 套支持快速应用开发的工具集CommonPoint，其中包括了上百个面向对象框架 [Andert 94,Cotter 95]。
框架目前还没有统一的定义，其中Ralph Johnson所给出的定义基本上为大多数研究人员所接受：
一个框架是一个可复用设计，它是由一组抽象类及其实例间协作关系来表达的 [Johnson 98]。
这个定义是从框架内涵的角度来定义框架的，当然也可以从框架用途的角度来给出框架的定义：
一个框架是在一个给定的问题领域内，一个应用程序的一部分设计与实现[Bosch 97]。
从以上两个定义可以看出，框架是对特定应用领域中的应用系统的部分设计和实现，它定义了一类应用系统(或子系统)的整体结构。框架将应用系统划分为类和对象，定义类和对象的责任，类和对象如何互相协作，以及对象之间的控制线程。这些共有的设计因素由框架预先定义，应用开发人员只须关注于特定的应用系统特有部分。框架刻画了其应用领域所共有的设计决策，所以说框架着重于设计复用，尽管框架中可能包含用某种程序设计语言实现的具体类。
一个基于框架开发的应用系统包含一个或多个框架，与框架相关的构件类，以及与应用系统相关的功能扩展。与应用系统相关的扩展包括与应用系统相关的类和对象。应用系统可能仅仅复用了面向对象框架的一部分，或者说，它可能需要对框架进行一些适应性修改，以满足系统需求。
面向对象的框架作为一种可复用的软件，在基于框架的软件开发过程中会涉及到框架的开发和利用两个方面的工作。框架的开发阶段在于产生领域中可复用的设计。 该阶段的主要结果是框架以及与框架相关的构件类。该阶段的一个重要活动是框架的演变和维护。象所有软件一样，框架也易于变化。产生变化的原因很多，如应用 出错，业务领域变化，等等。
不论是哪一种技术，最终都是为业务发展而服务的。从业务的角度来讲。首先，框架的是为了企业的业务发展和战略规划而服务的，他服从于企业的愿景 （vision）；其次，框架最重要的目标是提高企业的竞争能力，包括降低成本、提高质量、改善客户满意程度，控制进度等方面。最后，框架实现这一目标的 方式是进行有效的知识积累。软件开发是一种知识活动，因此知识的聚集和积累是至关重要的。框架能够采用一种结构化的方式对某个特定的业务领域进行描述，也 就是将这个领域相关的技术以代码、文档、模型等方式固化下来。
框架要解决的问题
框架要解决的最重要的一个问题是技术整合的问题，在框架中，有着各种各样的技术，不同的软件企业需要选择不同的技术，这就使得软件企业最终的应用依赖于这些技术，技术自身的复杂性和技术的风险 性将会直接对应用造成冲击。而应用是软件企业的核心，是竞争力的关键所在，因此应该将应用自身的设计和具体的实现技术解耦。这样，软件企业的研发将集中在 应用的设计上，而不是具体的技术实现，技术实现是应用的底层支撑，它不应该直接对应用产生影响。
要理解这一点，我们来举一些例子：
一个做视频流应用的软件企业，他为电广行业提供整体的解决方案。他的优势在于将各种各样的视频硬件、服务器、和管理结合起来，因此他扮演的是一个集成商的 角色。因此他的核心价值在于使用软件技术将不同的硬件整合起来，并在硬件的整合层面上提供一个统一的管理平台。所以他的精力应该放在解决两个问题：
如何找到一种方法，将不同的硬件整合起来，注意，这里的整合并不是技术整合，而是一种思路上的整合。首先要考虑的绝对不是要使用什么技术，而是这些硬件需 要提供哪些服务，需要以什么样的方式进行管理。因此，这时候做的事情实际上是对领域进行建模。例如，我们定义任何一种硬件都需要提供两种能力，一种是统一 的管理接口，用于对所有硬件统一管理；另一种是服务接口，系统平台可以查询硬件所能够提供的服务，并调用这些服务。所以，设计的规范将会针对两种能力进 行。
什么要用框架？
因为软件系统发展到今天已经很复杂了，特别是服务器端软件，设计到的知识，内容，问题太多。在某些方面使用别人成熟的框架，就相当于让别人帮你完成一些基 础工作，你只需要集中精力完成系统的业务逻辑设计。而且框架一般是成熟，稳健的，他可以处理系统很多细节问题，比如，事物处理，安全性，数据流控制等问 题。还有框架一般都经过很多人使用，所以结构很好，所以扩展性也很好，而且它是不断升级的，你可以直接享受别人升级代码带来的好处。框架一般处在低层应用平台和高层业务逻辑之间的中间层。为了实现“高内聚、低耦合”。把问题划分开来各个解决，易于控制，易于延展，易于分配资源…框架的分层设计已经被普遍接受。
为什么要进行框架开发?
框架的最大好处就是重用。面向对象系统获得的最大的复用方式就是框架，一个大的应用系统往往可能由多层互相协作的框架组成。
由于框架能重用代码，因此从一已有构件库中建立应用变得非常容易，因为构件都采用框架统一定义的接口，从而使构件间的通信简单。
框架能重用设计。它提供可重用的抽象算法及高层设计，并能将大系统分解成更小的构件，而且能描述构件间的内部接口。这些标准接口使在已有的构件基础上通过 组装建立各种各样的系统成为可能。只要符合接口定义，新的构件就能插入框架中，构件设计者就能重用构架的设计。
框架还能重用分析。所有的人员若按照框架的思想来分析事务，那么就能将它划分为同样的构件，采用相似的解决方法，从而使采用同一框架的分析人员之间能进行沟通。
采用框架技术进行软件开发的主要特点包括：
领域内的软件结构一致性好；
建立更加开放的系统；
重用代码大大增加，软件生产效率和质量也得到了提高；
软件设计人员要专注于对领域的了解，使需求分析更充分；
存储了经验，可以让那些经验丰富的人员去设计框架和领域构件，而不必限于低层编程；
允许采用快速原型技术；
有利于在一个项目内多人协同工作；
大粒度的重用使得平均开发费用降低，开发速度加快，开发人员减少，维护费用降低，而参数化框架使得适应性、灵活性增强。
与框架相关的概念
1. 白盒与黑盒框架
框架可分为白盒(White-Box)与黑盒(Black-Box)两种框架。
基于继承的框架被称为白盒框架。所谓白盒即具备可视性，被继承的父类的内部实现细节对子类 而言都是可知的。利用白盒框架的应用开发者通过衍生子类或重写父类的成员方法来开发系统。子类的实现很大程度上依赖于父类的实现，这种依赖性限制了重用的 灵活性和完全性。但解决这种局限性的方法可以是只继承抽象父类，因为抽象类基本上不提供具体的实现。白盒框架是一个程序骨架，而用户衍生出的子类是这个骨 架上的附属品。
基于对象构件组装的框架就是黑盒框架。应用开发者通过整理、组装对象来获得系统的实现。用户只须了解构件的外部接口，无须了解内部的具体实现。另外，组装比继承更为灵活，它能动态地改变，继承只是一个静态编译时的概念。
在理想情况下，任何所需的功能都可通过组装已有的构件得到，事实上可获得的构件远远不能满足需求，有时通过继承获得新的构件比利用已有构件组装新构件更容 易，因此白盒和黑盒将同时应用于系统的开发中。不过白盒框架趋向于向黑盒框架发展，黑盒框架也是系统开发希望达到的理想目标。
2. 热点、食谱以及好莱坞原则
成功的框架开发需要确定领域专用的“热点” (Hot spot)。应用开发者在框架的基础上进行开发，只须扩展框架的某些部分，“热点”就是在应用领域的一种扩展槽，开发者根据自己的需要填充这些扩展槽。 “热点”使框架具有灵活性，如在具体的实现中，扩展槽可以被看成是一些抽象类，开发者通过重写抽象方法获得具体实现。
“食谱” (Cookbook)就是描述如何使用框架方法的文档。在“食谱”中包含了许多“烹饪”方法，这些“烹饪”方法相当于一些具体的操作步骤，描述了为解决某一专门问题如何使用框架的详细方法。框架的内部设计和实现细节通常不出现在“食谱”中。
框架的一个重要特征就是用户定义的方法经常被框架自身调用，而不是从用户的应用代码中调用。这种机制常称为“好莱坞原则”(Hollywood Principle)或“别调用我们，我们会调用您”。
常见的C++框架有什么？
ACE：
全称：Adaptive Communication Enviroment
ACE自适配通信环境（ADAPTIVE Communication Environment）是可以自由使用、开放源码的面向对象（OO）框架（Framework），在其中实现了许多用于并发通信软件的核心模式。ACE提供了一组丰富的可复用C++ Wrapper Facade（包装外观）和框架组件，可跨越多种平台完成通用的通信软件任务，其中包括：事件多路分离和事件处理器分派、信号处理、服务初始化、进程间通信、共享内存管理、消息路由、分布式服务动态（重）配置、并发执行和同步，等等。
ACE的目标用户是高性能和实时通信服务和应用的开发者。它简化了使用进程间通信、事件多路分离、显式动态链接和并发的OO网络应用和服务的开发。此外，通过服务在运行时与应用的动态链接，ACE还使系统的配置和重配置得以自动化。
出处：http://www.cs.wustl.edu/~schmidt/ACE.html
说明: 小飞驴对ACE的技术文档作了翻译，有中文版的大量资料可查 http://www.flyingdonkey.com/ace/
ICE:
全称：Internet Communications Engine
Internet Communications Engine是ZeroC提 供的一款高性能的中间件，基于ICE可以实现电信级的解决方案。前面我们提到过在设计网站架构的时候可以使用ICE实现对网站应用的基础对象操作，将基础 对象操作和数据库操作封装在这一层，在业务逻辑层以及表现层(C++,java,php,.net,python)进行更丰富的表现与操作，从而实现比较好的架 构。基于ICE的数据层可以在未来方便的进行扩展。ICE支持分布式的部署管理，消息中间件，以及网格计算等等。
出处: http://www.zeroc.com/ice.html
说明: 小飞驴对ICE的技术文档作了翻译，可惜无法免费下载，也有中文版的大量资料可查
BOOST:
全称： Boost portable C++ libraries.
Boost库是一个经过千锤百炼、可移植、提供源代码的C++库，作为标准库的后备，是C++标准化进程的发动机之一。 Boost库由C++标准委员会库工作组成员发起，在C++社区中影响甚大，其成员已近2000人。 Boost库为我们带来了最新、最酷、最实用的技术，是不折不扣的“准”标准库。
出处: http://www.boost.org
说明: 恐怕是更新最快的库了， 非官方中文站 http://www.stlchina.org/twiki/bin/view.pl/Main/BoostChina
Loki:
全称： C++ library Loki
Loki(神中的混乱制造者)，也造成C++世界智能指针的混乱，不折不扣地模板化模式实现者！
出处: http://loki-lib.sourceforge.net/
总结
到目前为止，对于框架（战略模式）的研究远比设计模式(战术模式)的研究要少，这也可以理解，应为框架的构成与实现更为复杂，可在不同的领域与行业差别会更大，导致对于框架的认识是很不相同的。
框架的实现要依赖于模式，但是模式的简单堆积却构不成框架。可以肯定地是选择合适的框架会给软件开发工作注入澎湃的动力。如在以Apache为基础的Web服务器CGI程序中，目前主流是动态语言解释模块，mod_pytho,mod_perl,php都有成功的CGI框架，而我们还停留在十几年前的技术，用C写着CGI。恐怕不是因为我们技术力量不行，而是缺乏新技术的接纳的态度以及不断学习的激情！
稍微改一下伟人的名言: “战术上重视敌人，战略上更重视敌人，”
