面向对象的设计模式学习.docx

23种设计模式可以在功能设计，功能的编程实现设计，程序结构优化和性能优化等方面给我们以帮助。大部分模式我们在编程的过程中都已经无意识的使用过。每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这是面向对象编程人员必须掌握的一门内功。设计模式描述了软件设计过程中某一类常见问题的一般性的解决方案。面向对象设计模式描述了面向对象设计过程中、特定场景下、类与相互通信的对象之间常见的组织关系。整个设计模式贯穿一个原理:面对接口编程，而不是面对实现.目标原则是:降低耦合,增强灵活性. 1.1. 创建型创建型：负责对象创建。1、 Singleton，单例模式：定义：保证一个类只有一个实例，并提供一个访问它的全局访问点 。单例模式有延迟初始化和非延迟两种实现方式。单体模式注意事项：有时在某些情况下，使用Singleton并不能达到Singleton的目的，如有多个Singleton对象同时被不同的类装入器装载；在EJB这样的分布式系统中使用也要注意这种情况，因为EJB是跨服务器，跨JVM的。Singleton模式看起来简单，使用方法也很方便，但是真正用好，是非常不容易，需要对Java的类 线程 内存等概念有相当的了解。总之：如果你的应用基于容器，那么Singleton模式少用或者不用，可以使用相关替代技术。二、Abstract Factory，抽象工厂模式又称为工具箱，产生产品族，但不利于产生新的产品。定义：提供一个接口，让该接口负责创建一系列“相关或者相互依赖的对象”，无需指定它们具体的类。面向对象的设计中，我们使用“new”的方式来创建对象，这样的问题就是：我们依赖实现，不能应对“具体实例化类型”的变化。变化点在“对象创建”，因此就封装“对象创建”，面向接口编程依赖接口，而非依赖实现。AbstractFactory模式的几个要点1.如果没有应对“多系列对象创建”的需求变化，则没有必要使用AbstractFactory模式，这时候使用简单的静态工厂完全可以。2.系列对象指的是这些对象之间有相互依赖、或作用的关系，例如游戏开发场景中“道路”与“房屋”的依赖，“道路”与“地道”的依赖。3.AbstractFactory模式主要在于应对“新系列”的需求变动。其缺点在于难以应对“新对象”的需求变动。4.AbstractFactory模式经常和FactoryMethod模式共同组合来应对“对象创建”的需求变化。（FactoryMethod是应对对象的变化，）Builder模式和AbstractFactory模式的区别Builder模式更强调的是对象部分的“构建”这样一个严格的过程，它构建的是整个对象的各个部分。它把构建稳定下来之后，各个部分在变化，最后组合成一个整体的对象。AbstractFactory模式构建的是一组系列交互的对象。互相依赖、互相交互的对象和一个对象的各个部分是有区别的。三、Factory Method，工厂方法模式又称为多形性工厂；定义：一个用于创建对象的接口，让子类决定实例化哪一个类，Factory Method使一个类的实例化延迟到了子类。 1) 抽象工厂角色（AbstractCreator）：这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java中它由抽象类或者接口来实现。2) 具体工厂角色(Creator)：它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。3) 抽象产品角色(AbstractProduct)：它是具体产品继承的父类或者是实现的接口。在java中一般有抽象类或者接口来实现。4) 具体产品角色(Product)：具体工厂角色所创建的对象就是此角色的实例。在java中由具体的类来实现。四、Builder，建造模式建造模式，又叫生成器模式。定义:将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示.Builder模式主要用于“分步骤构建一个复杂的对象”。在这其中“分步骤”是一个稳定的算法（即Director），而复杂对象的各个部分（即ConcreteBuilder）则经常变化。变化点在哪里，封装哪里Builder模式主要在于应对“复杂对象各个部分”的频繁需求变动。其缺点在于难以应对“分步骤构建算法”的需求变动。（例如房屋构造如果经常改变，那么这个Builder模式也没有意义了）AbstractFactory模式解决“系列对象”的需求变化，Builder模式解决“对象部分”的需求变化。Builder模式通常和Composite模式组合使用。应用举例：数据库连接池（每一个连接的重用）五、Prototype，原始模型模式定义：用原型实例指定创建对象的种类，并且通过拷贝这些原型来创建新的对象。 通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类，产品类不需要非得有任何事先确定的等级结构，原始模型模式适用于任何的等级结构。缺点是每一个类都必须配备一个克隆方法。在Java中Prototype模式变成clone()方法的使用，由于Java的纯洁的面向对象特性，使得在Java中使用设计模式变得很自然，两者已经几乎是浑然一体了。这反映在很多模式上，如Interator遍历模式。1.2. 行为型行为型：类与对象交互中的职责分配。六、Iterator，迭代器模式：迭代器模式，又叫游标模式，定义:提供一种方法访问一个容器（container）对象中各个元素，而又不需暴露该对象的内部细节。这个模式已经被整合入Java的Collection.在大多数场合下无需自己制造一个Iterator,只要将对象装入Collection中，直接使用Iterator进行对象遍历1) 迭代器角色（Iterator）：迭代器角色负责定义访问和遍历元素的接口。（Iterator）2) 具体迭代器角色（Concrete Iterator）：具体迭代器角色要实现迭代器接口，并要记录遍历中的当前位置。3) 容器角色（Container）：容器角色负责提供创建具体迭代器角色的接口。4) 具体容器角色（Concrete Container）：具体容器角色实现创建具体迭代器角色的接口。多个对象聚在一起形成的总体称之为聚合，聚合对象是能够包容一组对象的容器对象。迭代模式将迭代逻辑封装到一个独立的子对象中，从而与聚合本身隔开。迭代子模式简化了聚合的界面。每一个聚合对象都可以有一个或一个以上的迭代子对象，每一个迭代子的迭代状态可以是彼此独立的。迭代算法可以独立于聚合角色变化。七、Observer，观察者模式：定义：定义对象间的一种一对多的依赖关系，以便当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并自动更新。观察者模式定义了一种一队多的依赖关系，让多个观察者对象（observer Object）同时监听某一个主题对象(subject Object)。这个主题对象在状态上发生变化时，会通知所有观察者对象，使他们能够自动更新自己。应用举例：电子商务中，商品的变化，通知关注的用户。Java的API还为为我们提供现成的Observer接口Java.util.Observer,八、Template Method，模板方法模式定义:定义一个操作中算法的骨架,将一些步骤的执行延迟到其子类中. Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。介绍：变化是软件设计的永恒主题，如何管理变化带来的复杂性？设计模式的艺术性和复杂度就在于如何分析，并发现系统中的变化点和稳定点，并使用特定的设计方法来应对这种变化.如果你只想掌握一种设计模式，那么它就是Template Method！Template Method模式是一种非常基础性的设计模式，在面向对象系统中有着大量的应用。它用最简洁的机制（虚函数的多态性）为很多应用程序框架提供了灵活的扩展，是代码复用方面的基本实现结构。模板方法模式准备一个抽象类，将部分逻辑以具体方法以及具体构造方法的形式实现，然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法，从而对剩余的逻辑有不同的实现。先制定一个顶级逻辑框架，而将逻辑的细节留给具体的子类去实现。应用举例：九、Command，命令模式：定义：将一个请求封装为一个对象，从而使你可用不同的请求对客户（客户程序，也是行为的请求者）进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。Command：定义命令的接口，声明执行的方法。ConcreteCommand：命令接口实现对象，是“虚”的实现；通常会持有接收者，并调用接收者的功能来完成命令要执行的操作。Receiver：接收者，真正执行命令的对象。任何类都可能成为一个接收者，只要它能够实现命令要求实现的相应功能。Invoker： 要求命令对象执行请求，通常会持有命令对象，可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方，也就是说相当于使用命令对象的入口。Client：创建具体的命令对象，并且设置命令对象的接收者。注意这个不是我们常规意义上的客户端，而是在组装命令对象和接收者，或许，把这个Client称为装配者会更好理解，因为真正使用命令的客户端是从Invoker来触发执行。命令模式把一个请求或者操作封装到一个对象中。命令模式把发出命令的责任和执行命令的责任分割开，委派给不同的对象。命令模式允许请求的一方和发送的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否执行，何时被执行以及是怎么被执行的。系统支持命令的撤消。命令模式解决的问题：在软件构建过程中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合比如需要对行为进行“记录、撤销/重做（undo/redo）、事务”等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将“行为请求者”与“行为实现者”解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。命令模式的要点：Command模式的根本目的在于将“行为请求者”与“行为实现者”解耦，在面向对象语言中，常见的实现手段是“将行为抽象为对象”。实现Command接口的具体命令对象ConcreteCommand有时候根据需要可能会保存一些额外的状态信息。通过使用Composite模式，可以将多个“命令”封装为一个“复合命令”MacroCommand。应用举例：调度服务器，activeMQ服务器，监测点客户端。十、State，状态模式：定义: 不同的状态,不同的行为;或者说,每个状态有着相应的行为。 状态改变引起行为改变状态模式允许一个对象在其内部状态改变的时候改变行为，这个对象看上去象是改变了它的类一样。状态模式把所研究的对象的行为包装在不同的状态对象里，每一个状态对象都属于一个抽象状态类的一个子类。1) 使用环境（Context）角色：客户程序是通过它来满足自己的需求。它定义了客户程序需要的接口；并且维护一个具体状态角色的实例，这个实例来决定当前的状态。2) 状态（State）角色：定义一个接口以封装与使用环境角色的一个特定状态以及和这个特定状态相关的行为。3) 具体状态（Concrete State）角色：实现状态角色定义的接口。类图，结构非常简单也与策略模式非常相似。状态模式的意图是让一个对象在其内部状态改变的时候，其行为也随之改变。状态模式需要对每一个系统可能取得的状态创立一个状态类的子类。当系统的状态变化时，系统便改变所选的子类。应用举例：hibernate的对象持久化，登录用户锁定，PS中工具箱等。优缺点：1)优点: 避免了为判断状态而产生的巨大的if或case语句。 将对象行为交给状态类维护后，对于上层程序而言，仅需要维护状态之间的转换规则。2)会导致某些系统有过多的具体状态类。适用性1）一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为。2）一个对象含有庞大的条件分支语句，这些分支依赖于它的状态。这个状态通常用一个或多个枚举常量表示。通常有多个操作包含这一相同的结构。State模式将每一个分支放入一个独立的类中。这使得你可以根据对象自身的情况将对象的状态作为一个对象，这一对象可以不依赖于其他对象而独立变化。十一、Strategy，策略模式：定义：定义一系列的算法，把他们一个个封装起来，并使他们可以互相替换，此模式使得算法可以独立于使用它们的客户。 l Strategy及其子类为组件提供了一系列可重用的算法策略模式针对一组算法，将每一个算法封装（封装性）到具有共同接口的独立的类中，从而可以使得类型在运行时方便地根据需要在各个算法之间进行切换，使得算法可以在不影响到客户端的情况下发生变化（透明性）。l 算法与对象本身解耦策略模式把行为和环境分开。环境类负责维持和查询行为类，各种算法在具体的策略类中提供。由于算法和环境独立开来，算法的增减，修改都不会影响到环境和客户端。l Strategy类型里面不携带状态信息Strategy类型里面不携带状态信息（这是与模板方法的区别，模板方法本身是携带状态信息的），我们不能把它看成一种实例，即使有状态，也是会通过参数传入。l Strategy是独立的一个Strategy定义了一个算法的完整步骤和结构，只要用一个Strategy具体类，就可以完成整个算法的操作，不会有其它依赖和耦合。l Strategy模式提供了用条件判断语句以外的另一种选择，消除条件判断语句，就是在解耦合。含有许多条件判断语句的代码通常都需要Strategy模式。l 与State类似，如果Strategy对象没有实例变量，那么各个上下文可以共享一个Strategy对象，从而节省对象开销。l Strategy模式适用的是算法结构中整个算法的改变，而不是算法中某个部分的改变。策略模式和模版模式的区别：1）策略模式针对的是一个整个算法改变。模版模式针对的是算法中某个或某几个部分的改变。2）策略模式是把行为和环境分开；而模版模式是把行为和行为实现延迟。应用举例：以不同的格式保存文件, 以不同的算法压缩文件,截取不同形状的图片等。十二、China of Responsibility，职责链模式：定义：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递请求，直到有一个对象处理它为止。请求在这个链上传递，直到链上的某一个对象决定处理此请求。客户并不知道链上的哪一个对象最终处理这个请求，系统可以在不影响客户端的情况下动态的重新组织链和分配责任。一个请求可能有多个接受者，但是最后真正的接受者只有一个。一个请求可以最终不被任何接收端对象所接受。处理者有两个选择：承担责任或者把责任推给下家。纯的责任链模式 : 规定一个具体处理者角色只能对请求作出两种动作：自己处理；传给下家。不能出现处理了一部分，把剩下的传给了下家的情况。而且请求在责任链中必须被处理，而不能出现无果而终的结局。责任链的“链”只是为了说明一种传递的思想，在实现的过程中实际可以直线，树状，环状等。责任链模式优缺点:降低了耦合、提高了灵活性。但是责任链模式可能会带来一些额外的性能损耗，因为它每次执行请求都要从链子开头开始遍历。责任链的维护：组建责任连接，这里我们自己维护。以参考使用list 或者map 来进行注册。可以使用spring 来管理具体处理者角色的引入。当有了新的处理者需要添加的时候，仅仅需要修改下配置文件。应用举例：处理UI的消息古代：墨子.迎敌祠里描守城军队的结构：“城上步一甲、一戟，其赞三人。五步有伍长，十步有什长，百步有佰长，旁有大帅，中有大将，皆有司吏卒长。”十三、Mediator，中介者模式中介者模式又叫调停者模式。定义:用一个中介对象来封装一系列关于对象交互行为.中介者使各个对象不需要显示地相互引用，从而使其耦合性松散，而且可以独立地改变他们之间的交互。用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式的相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。当某些对象之间的作用发生改变时，不会立即影响其他的一些对象之间的作用。保证这些作用可以彼此独立的变化。调停者模式将多对多的相互作用转化为一对多的相互作用。调停者模式将对象的行为和协作抽象化，把对象在小尺度的行为上与其他对象的相互作用分开处理。应用： 在软件构建过程中，经常会出现多个对象互相关联交互的情况，对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将面临不断地变化。在这种情况下，我们可使用一个“中介对象”来管理对象间的关联关系，避免相互交互的对象之间的紧耦合引用关系，从而更好地抵御变化。应用举例：聊天室程序。随着控制逻辑的复杂化，Mediator具体对象的实现可能相当复杂。这时候可以对Mediator对象进行分解处理。十四、Visitor，访问者模式：定义：作用于某个对象群中各个对象的操作. 它可以使你在不改变这些对象本身的情况下,定义作用于这些对象的新操作.简单的说，就是对象不变，作用于对象的操作变化时，可采用该模式。使用Visitor模式的前提：使用访问者模式是对象群结构中(Collection) 中的对象类型很少改变。在两个接口Visitor（访问者）和Visitable（可访者）中,确保Visitable很少变化,也就是说，确保不能老有新的Element元素类型加进来，可以变化的是访问者行为或操作,当需要添加新的操作的时候，只需要添加一个Visitor实现类即可。这种结构把扩展操作所带来的改变转嫁给了Visitor的子类。不但Visitor实现要变化，Visistable也要增加相应行为，GOF建议是,不如在这些对象类中直接逐个定义操作，无需使用访问者设计模式（但在java中，可结合使用java的反射机制解决这种情况）。应用举例：各大互联网服务商 提出的所谓的应用开放平台，跟这种思路相似。十五、Interpreter，解释器模式：定义：给定一个语言，定义它的文法的一种表示，并提供一个解释器，来解释该语言中的句子。给定一个语言后，可以定义出其文法的一种表示，并同时提供一个解释器。客户端可以使用这个解释器来解释这个语言中的句子。解释器模式将描述怎样在有了一个简单的文法后，使用模式设计解释这些语句。在解释器模式里面提到的语言是指任何解释器对象能够解释的任何组合。在解释器模式中需要定义一个代表文法的命令类的等级结构，也就是一系列的组合规则。每一个命令对象都有一个解释方法，代表对命令对象的解释。命令对象的等级结构中的对象的任何排列组合都是一个语言。应用举例：把阿拉伯数字变成中文数字，把日期变成农历的日期，Quartz表达式的解释，正则表达式，sql语句等。气象局数据判断分析项目：用到数据过滤器。(T 50000 : 60000 or T 70000 : 80000 or T 90000 : 95000 or T 100000 : 180000)。 十六、Memento，备忘录模式：定义：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。备忘录对象（Memento对象）是一个用来存储另外一个对象内部状态的快照的对象。缺点：Memento模式的缺点是耗费大,如果内部状态很多,再保存一份,无意要浪费大量内存.应用举例：JSP+JavaBean 开发中，表单信息的记录。1.3. 结构型结构型：处理类与对象间的组合。十七、Composite，组合模式：组合模式又叫合成模式。定义：将对象以树形结构组织起来,以达成“部分整体” 的层次结构，使得客户端对单个对象和组合对象的使用具有一致性.l 合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。l Composite使得用户对单个对象和组合对象的使用具有一致性。l 合成模式就是一个处理对象的树结构的模式。l 合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。看下组合模式的组成。1) 抽象构件角色(Component)：它为组合中的对象声明接口，也可以为共有接口实现缺省行为。2) 树叶构件角色(Leaf)：在组合中表示叶节点对象没有子节点，实现抽象构件角色声明的接口。3) 树枝构件角色(Composite)：在组合中表示分支节点对象有子节点，实现抽象构件角色声明的接口；存储子部件。组合模式中必须提供对子对象的管理方法，不然无法完成对子对象的添加删除等操作。但是管理方法是在Component 中就声明还是在Composite中声明呢？一种方式是在Component 里面声明所有的用来管理子类对象的方法，以达到Component 接口的最大化。目的就是为了使客户看来在接口层次上树叶和分支没有区别透明性。但树叶是不存在子类的，因此Component 声明的一些方法对于树叶来说是不适用的。这样也就带来了一些安全性问题。另一种方式就是只在Composite 里面声明所有的用来管理子类对象的方法。这样就避免了上一种方式的安全性问题，但是由于叶子和分支有不同的接口，所以又失去了透明性。设计模式一书认为：在这一模式中，相对于安全性，我们比较强调透明性。对于第一种方式中叶子节点内不需要的方法可以使用空处理或者异常报告的方式来解决。十八、Facade，外观模式：外观模式又叫门面模式。定义: 为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。直接访问模式。外观模式外观模式减少了客户程序和子系统之间的耦合，增加了可维护性.外观模式有3个角色（门面角色，子系统角色，客户端角色）。1) 门面角色（facade）：这是门面模式的核心。它被客户角色调用，因此它熟悉子系统的功能。它内部根据客户角色已有的需求预定了几种功能组合。2) 子系统角色：实现了子系统的功能。对它而言，facade角色就和客户角色一样是未知的，它没有任何facade角色的信息和链接。3) 客户角色：调用facade角色来完成要得到的功能。外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。每一个子系统只有一个门面类，而且此门面类只有一个实例，也就是说它是一个单例模式。但整个系统可以有多个门面类。要点：1 外观模式为复杂子系统提供了一个简单接口，并不为子系统添加新的功能和行为。2 外观模式实现了子系统与客户之间的松耦合关系。3 外观模式没有封装子系统的类，只是提供了简单的接口。如果应用需要，它并不限制客户使用子系统类。因此可以在系统易用性与通用性之间选择。4 外观模式注重的是简化接口，它更多的时候是从架构的层次去看整个系统，而并非单个类的层次。5 外观模式经常使用单例实现，但子系统们可以有多个Faade。使用时的注意项：2. 子系统可以由Faade调用，也可以由Client直接调用。3. 子系统不知道Faade的存在，对于子系统，Faade只是一个Client。 协作：1. 客户程序通过发送请求给Faade的方式与子系统通讯，Faade将这些消息转发给适当的子系统对象。2. 使用Faade的客户程序不需要直接访问子系统对象。适用性：1. 为一个复杂子系统提供一个简单接口。2. 减少子系统之间以及子系统与客户端的依赖性，提高子系统的独立性和可移植性。3. 在层次化结构中，可以使用Facade模式定义系统中每一层的入口。简化各层之间的依赖。十九、Proxy，代理模式： 定义：为其他对象提供一种代理以控制对这个对象的访问。某些情况下，客户不想或者不能够直接引用一个对象，代理对象可以在客户和目标对象直接起到中介的作用。客户端分辨不出代理主题对象与真实主题对象。代理模式可以并不知道真正的被代理对象，而仅仅持有一个被代理对象的接口，这时候代理对象不能够创建被代理对象，被代理对象必须有系统的其他角色代为创建并传入。1) 抽象主题角色：声明了真实主题和代理主题的共同接口。2) 代理主题角色：内部包含对真实主题的引用，并且提供和真实主题角色相同的接口。3) 真实主题角色：定义真实的对象。Proxy模式的几个要点“增加一层间接层”是软件系统中对许多复杂问题的一种常见解决方法。在面向对象系统中，直接使用某些对象会来带很多问题，作为间接层的Proxy对象便是解决这一问题的常用手段。具体Proxy设计模式的实现方法、实现粒度都相差很大，有些可能对单个对象做细粒度的控制，有些可能对组件模块提供抽象代理层，在架构层次对对象做Proxy。Proxy并不一定要求保持接口的一致性，只要能够实现间接控制，有时候损及一些透明性是可以接受的。总结：代理模式能够协调调用者和被调用者，能够在一定程度上降低系统的耦合度。代理模式中的真实主题角色可以结合组合模式来构造，这样一个代理主题角色就可以对一系列的真实主题角色有效，提高代码利用率，减少不必要子类的产生。举例：现在流行的分布计算方式RMI等都是Proxy模式的应用.。二十、Adapter,适配器模式：定义：将一个类的接口转换成客户希望的另一个接口。从而使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。适配类可以根据参数返还一个合适的实例给客户端。举例：java 的Swing编程中常用。二十一、Decrator，装饰模式：装饰模式（Decorator）也叫包装器模式（Wrapper）定义：动态地给一个对象增加一些额外的职责。就增加的功能来说，Decorator模式相比生成子类更加灵活。装饰模式的组成。1) 抽象构件角色（Component）：定义一个抽象接口，以规范准备接收附加责任的对象。2) 具体构件角色(Concrete Component)：这是被装饰者，定义一个将要被装饰增加功能的类。3) 装饰角色(Decorator)：持有一个构件对象的实例，并定义了抽象构件定义的接口。4) 具体装饰角色(Concrete Decorator)：负责给构件添加增加的功能。装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案，提供比继承更多的灵活性。动态给一个对象增加功能，这些功能可以再动态的撤消。增加由一些基本功能的排列组合而产生的非常大量的功能。适用性：以下情况使用Decorator模式1. 需要扩展一个类的功能，或给一个类添加附加职责。2. 需要动态的给一个对象添加功能，这些功能可以再动态的撤销。3. 需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继承关系变的不现实。4. 当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。 优点：1. Decorator模式与继承关系的目的都是要扩展对象的功能，但是Decorator可以提供比继承更多的灵活性。2. 通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合。缺点：1. 这种比继承更加灵活机动的特性，也同时意味着更加多的复杂性。2. 装饰模式会导致设计中出现许多小类，如果过度使用，会使程序变得很复杂。3. 装饰模式是针对抽象组件（Component）类型编程。但是，如果你要针对具体组件编程时，就应该重新思考你的应用架构，以及装饰者是否合适。当然也可以改变Component接口，增加新的公开的行为，实现“半透明”的装饰者模式。在实际项目中要做出最佳选择。应用举例：java的I/O实现。二十二、Bridge，桥模式：定义：将抽象和行为划分开来,使他们可以独立的变化,但能动态的结合。在面向对象设计的基本概念中，对象这个概念实际是由属性和行为两个部分组成的，属性我们可以认为是一种静止的，是一种抽象，一般情况下，行为是包含在一个对象中，但是，在有的情况下，我们需要将这些行为也进行归类，形成一个总的行为接口，这就是桥模式的用处。如果不希望抽象部分和行为有一种固定的绑定关系，而是应该可以动态联系的。我们就可以考虑桥模式。将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以独立的变化（“组合优先于继承”的思想）。应用举例：数据库访问的DAO模式。二十三、Flyweight，享元模式定义：运用共享技术有效地支持大量细粒度的对象。避免大量拥有相同内容的小类的开销(如耗费内存),使大家共享一个类(元类).享元模式的特点是，复用我们内存中已存在的对象，降低系统创建对象实例的性能消耗，类似于缓存的思想。享元模式以共享的方式高效的支持大量的细粒度对象。享元模式能做到共享的关键是区分“内蕴状态”和“外蕴状态”。内蕴状态存储在享元内部，不会随环境的改变而有所不同。外蕴状态是随环境的改变而改变的。外蕴状态不能影响内蕴状态，它们是相互独立的。将可以共享的状态和不可以共享的状态从常规类中区分开来，将不可以共享的状态从类里剔除出去。客户端不可以直接创建被共享的对象，而应当使用一个工厂对象负责创建被共享的对象。享元模式大幅度的降低内存中对象的数量。抽象享元角色(Flyweight类)：此角色是所有的具体享元类的超类，为这些类规定出需要实现的公共接口。那些需要外蕴状态的操作可以通过调用商业方法以参数形式传入。 具体享元(ConcreteFlyweight)角色：实现抽象享元角色所规定的接口。如果有内蕴状态的话，必须负责为内蕴状态提供存储空间。享元对象的内蕴状态必须与对象所处的周围环境无关，从而使得享元对象可以在系统内共享的。享元工厂(FlyweightFactory) 角色：本角色负责创建和管理享元角色。本角色必须保证享元对象可以被系统适当地共享。当一个客户端对象调用一个享元对象的时候，享元工厂角色会检查系统中是否已经有一个复合要求的享元对象。如果已经有了，享元工厂角色就应当提供这个已经有的享元对象；如果系统中没有一个适当的享元对象的话，享元工厂角色就应当创建一个合适的享元对象。客户端(Client)角色：本角色需要维护一个对所有享元对象的引用。本角色需要自行存储所有享元对象的外蕴状态Flyweight模式的几个要点面向对象很好地解决了抽象性的问题，但是作为一个运行在机器中的程序实体，我们需要考虑对象的代价问题。Flyweight设计模式主要解决面向对象的代价问题，一般不触及面向对象的抽象性问题。Flyweight采用对象共享的做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力。在具体实现方面，要注意对象状态的处理。享元模式的优点：它大幅度地降低内存中对象的数量。但是，它做到这一点所付出的代价也是很高的， 享元模式使得系统更加复杂，为了使对象可以共享，需要将一些状态外部化，这使得程序的逻辑复杂化。 享元模式将享元享元对象的状态外部化，而读取外部状态使得运行时间稍微变长。缺点：它使得系统逻辑复杂化，而且在一定程度上外蕴状态影响了系统的速度。1.4. 设计模式的总结1.4.1各设计模式的总结。创建型模式Singleton模式解决的是实体对象个数的问题。除了Singleton之外，其他创建型模式解决的都是new所带来的耦合关系。Factory Method，Abstract Factory，Builder都需要一个额外的工厂类来负责实例化“易变对象”，而Prototype则是通过原型（一个特殊的工厂类）来克隆“易变对象”。如果遇到“易变类”，起初的设计通常从Factory Method开始，当遇到更多的复杂变化时，再考虑重构为其他三种工厂模式（Abstract Factory，Builder，Prototype）。结构型模式Adapter模式注重转换接口，将不吻合的接口适配对接（适合于旧系统）Bridge模式注重分离接口与其实现，支持多维度变化Composite模式注重统一接口，将“一对多”的关系转化为“一对一”的关系Decorator模式注重稳定接口，在此前提下为对象扩展功能Facade模式注重简化接口，简化组件系统与外部客户程序的依赖关系Flyweight模式注重保留接口，在内部使用共享技术对对象存储进行优化，Flyweight 设计模式主要解决面向对象的代价问题Proxy模式注重假借接口，增加间接层来实现灵活控制行为型模式Template Method模式封装算法结构，支持算法子步骤变化Strategy模式注重封装算法，支持算法的变化State模式注重封装与状态相关的行为，支持状态的变化Memento模式注重封装对象状态变化，支持状态保存/恢复Mediator模式注重封装对象间的交互，支持对象交互的变化Chain Of Responsibility模式注重封装对象责任，支持责任的变化Command模式注重将请求封装为对象，支持请求的变化Iterator模式注重封装集合对象内部结构，支持集合的变化Interpreter模式注重封装特定领域变化，支持领域问题的频繁变化Observer模式注重封装对象通知，支持通信对象的变化Visitor模式注重封装对象操作变化，支持在运行时为类层次结构动态添加新的操作1.4.2模式之间的关系图1.4.3设计模式应用结束语l 设计模式建立在对系统变化点的基础上进行，哪里有变化点，哪里应用设计模式。l 设计模式应该以演化的方式来获得，系统的变化点往往是经过不断演化才能准确定位。l 不能为了模式而模式，设计模式是一种软件设计的软力量，而非规范标准。不应夸大设计模式的作用。l 不要刻意的去使自己的代码来符合一个模式的公式。只要能