设计模式总结范文.doc

设计模式总结范文 七大设计原则单一职责原则（SRP）对于一个类，应该只有一个导致其变化的原因。 涉及模式门面、Proxy开闭原则（OCP）设计一个模块时，应该使该模块在不被修改的前提下被扩展，即可在不必修改源代码的情况下改变该模块的行为。 对扩展开放，对更改封闭。 抽象化是关键。 涉及模式Strategy,Simple Factory,Factory Method,Abstract Factory,Builder,Bridge,门面，Mediator.里氏替换原则（LSP）一个软件实体如果使用的是一个基类的话，一定适用于其子类，而且根本不能觉察出基类对象和子类对象的区别。 （在软件中如果能够使用基类对象，那么一定能够使用其子类对象）尽量从抽象类继承而不从具体类继承；如果两个具体类A和B有继承关系，那么最简单的是建立一个抽象类C，让A和B成为C的子类；如果有一个由继承关系形成的等级结构，则所有树叶节点应该是具体类而所有树枝节点应该是抽象类或接口。 涉及模式Strategy,Composite,Proxy依赖倒置原则（DIP）高层模块不应该依赖低层模块，它们都应该依赖抽象。 抽象不应该依赖于细节，细节应该依赖于抽象。 针对接口编程，不要针对实现编程。 关键是以抽象方式耦合。 涉及模式Factory Method,Prototype,Iterator.接口隔离原则（ISP）使用多个专门的接口比使用单一的总接口要好。 不应该强迫客户依赖于他们不用的方法；一个类的不内聚的“胖接口”应该被分解为多组方法，每一组方法都服务于一组不同的客户程序。 涉及模式Memento,Iterator.组合/聚合复用原则（CARP）尽量使用组合/聚合，而不要使用继承。 继承是类型复用，白箱复用，使得超类的细节被暴露给子类，当超类修改时，子类也被迫修改；组合/聚合可以将已有的对象纳入到新对象中，使之成为新对象的一部分，因此新对象可以调用已有对象的功能，是黑箱复用。 如果两个类是“Hasa”关系而非”Isa”关系，但设计成继承，肯定违反LSP。 迪米特法则（LoD）一个对象应该对其他对象又尽可能少的了解。 （不要和陌生人说话）狭义如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。 如果其中的一个类需要调用另一个类的某一个方法，可以通过第三者转发这个调用。 广义对对象之间的信息流量、流向以及信息的影响进行控制；充分体现封装的概念。 基本原则只跟直接依赖的对象通信(不要耦合没有明显通信需求的2个对象)涉及模式门面、Mediator.GRASP核心是自己干自己能干的事，自己只干自己的事，也就是职责的分配和实现高内聚。 GRASP是对象职责分配的基本原则。 包括9个模式1)Information Expert信息专家将责任分配给信息专家，信息专家是指具有履行职责所需信息的类（实现高内聚）。 信息专家模式是面向对象设计的最基本原则。 优点信息的拥有者类同时就是信息的操作者类，可以减少不必要的类之间的关联；各类的职责单一明确，容易理解。 满足了面向对象设计的封装的思想。 对应于面向对象设计原则中的单一职责原则。 2)Creator创建者谁来创建？当以下条件之一为真时，将创建类A实例的职责分配给类B B容纳A；B聚集A；B具有A的初始化数据；B记录A；B频繁使用A。 优点整个结构清晰易懂；有利于类或组件的重用；防止职责的分散；降低耦合性。 与各种工厂模式相对应（简单工厂、工厂方法、抽象工厂）3)Low coupling低耦合如何减少变化所产生的影响？责任的分配要使（不必要的）耦合保持最低。 耦合主要指不同类之间相互关联的紧密程度，应该以降低类之间的耦合关系作为职责分配的原则。 4)High cohesion高内聚如何保持对象有重点、可理解和可管理，同时还要支持低耦合的作用？责任的分配要保持高内聚。 紧密相关的功能（职责）应该分配给同一个类。 低内聚的类存在难以被理解和维护，难实现类的重用，系统脆弱不断需要修改的缺点（难理解、难复用、难维护、脆弱）高内聚优点可表现关联责任的一个抽象，易于实现类的重用；使维护工作变得简单；使得系统模块化工作，方便团队工作。 模式优点聚集相关功能，结构清晰，容易理解；类的职责单一明确，降低类的复杂程度，使用简单，有利于重用；适应需求变化，一旦发生变化时，可以把影响缩小到最小范围。 高内聚与低耦合模式是GRASP其他模式的根本。 5)Controller控制器Q在UI层之上第一个接受和协调（控制）系统操作的对象是哪个？（谁应该负责处理一个输入系统事件？）A将职责分配给代表一下选择之一事物对象a)代表整个“系统”、“跟对象”、运行软件的设备，或者是主要的子系统；b)代表发生该系统操作的用例场景。 （对于同一用例场景的所有系统事件使用相同的控制器类）A把接收或者处理系统事件消息的职责分配给一个类。 这个类可以代表整个系统、设备或者子系统；系统事件发生时对应的用例场景，在相同的用例场景中使用相同的控制器来处理所有的系统事件。 GRASP共识系统事件的接收与处理通常由一个高级类来代替；一个子系统会有很多控制器类，分别处理不同的事务。 正常情况下，控制器类应该把需要完成的工作委派给其他的对象。 控制器只是协调或控制这些活动，本身并不完成大量的工作。 优点提高了重用的可能性，提供了可插拔的接口它保证了接口层不处理应用逻辑；对用例的状态进行推理（保证系统操作以合法的顺序发生）。 6)Polymorphism多态GRASP扩展模式的一种。 Q当行为基于类型变化时，谁对此负责？A当相关候选者或行为基于类型（类）而变化时，使用多态操作将行为职责分配给行为所变化的类型。 也即是说尽量对抽象层编程，用多态的方法来判断具体应该使用哪个类，而不是用if instanceof来判断该类是什么，执行什么。 优点易于增加新变化所需的扩展（只要实现了统一的通用接口，便可以实现行为的扩展）；无需影响客户便能够引入新的实现；避免重复代码；避免重复的分歧条件。 缺点不要为那些假想中的变化添加太多的多态。 GOF中的体现适配器、命令、组合、观察者、策略等7)Pure Fabrication纯虚构GRASP扩展模式之一把非问题域中的职责分配给人工定义的类。 原则是将非问题域的职责分配给人工生成、在业务逻辑之外加的类。 所谓问题域中的类是指从现实世界的对象抽象出来的类。 纯虚构模式是一种以功能为中心的对象或行为对象。 用于解决高内聚和低耦合之间的矛盾，它要求将一部分类的职责转移到纯虚构类中。 GOF中的体现适配器、策略模式等8)Indirection间接/中介GRASP模式中解决类关联问题的模式Q如何分配职责以避免直接耦合？A将职责分配给中介对象，由该对象来协调其他构建或服务，以避免其直接耦合。 优点高内聚（通过把”关联“的功能分散到第三方类，原来的类可以更加关注自身功能的实现）；低耦合（原本关联类之间不直接关联，降低类之间的耦合性）；高重用性（第三方类对”关联“功能的集中处理，与原来的类对自身功能的专注，有利于类的重用）。 GOF中体现Fa?ade（门面）、mediator模式、代理模式、中介者模式等对应迪米特法则。 9)Protected Variations变化预防GRASP扩展模式之一Q如何给对象、子系统和系统分配职责，以使这些元素中的变化或不稳定性不会对其他元素产生不良影响？A确定预计变化或不稳定之处，（在其外部）为其创建稳定“接口”以分配职责。 优点提高系统对变化的应对能力；高内聚；低耦合。 与开闭原则相对应。 大多数设计原则和GOF模式都是变化预防模式的体现。 GRASP小结主要特征对象职责分配的基本原则；主要应用在分析和建模上。 核心思想的理解自己干自己的事（职责的分配）；自己干自己的能干的事（职责的分配）；自己只干自己的事（职责的内聚）GOF设计模式按目的分创建型用于创建对象；结构型用于处理类或对象的组合；行为型用于描述对类或对象怎样交互和怎样分配职责。 按范围分类模式处理类和子类之间的关系，属于静态；对象模式处理对象之间的关系，动态。 创建型模式对类的实例化过程进行了抽象，能够将软件模块中对象的创建和对象的使用分离。 目的就是封装对象创建的变化。 结构型模式，关注的是对象之间组合的方式。 行为型模式关注的是对象的行为，需要做的是对变化的行为进行抽象，通过封装以达到整个架构的可扩展性。 策略模式，就是将可能存在变化的策略或算法抽象为一个独立的接口或抽象类，以实现策略扩展的目的。 Command模式、State模式、Vistor模式、Iterator模式概莫如是。 或者封装一个请求（Command模式），或者封装一种状态（State模式），或者封装“访问”的方式（Visitor模式），或者封装“遍历”算法（Iterator模式）。 而这些所要封装的行为，恰恰是软件架构中最不稳定的部分，其扩展的可能性也最大。 将这些行为封装起来，利用抽象的特性，就提供了扩展的可能。 创建型模式简单工厂简单工厂模式是由一个工厂类根据传入的参量决定创建出哪一种产品类的实例，涉及工厂角色(Creator)、抽象产品(Product)角色及具体产品(Concrete Product)角色等三个角色。 在简单工厂模式中，可以根据参数的不同返回不同类的实例。 简单工厂模式专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。 设计原则只在有限的程度上符合“开闭”原则。 “开闭”原则要求系统允许当新的产品加入系统时，无需对现有代码进行修改。 这一点对于产品的消费角色是成立的，而对于工厂角色不成立！适用场景工厂类负责创建的对象比较少；客户端只知道传入工厂类的参数，对于如何创建对象不关心。 工厂方法（关键特征平行等级结构）符合开闭原则，符合迪米特法则，符合依赖倒臵原则，符合里氏替换原则。 引入原因简单工厂中增加新产品时需要修改工厂类代码，违反OCP。 解决办法引入了抽象工厂角色，抽象工厂可以是接口，也可以是抽象类，将实际创建工作推迟到子类中。 典型代码抽象工厂中声明了工厂方法但并未实现工厂方法，具体产品对象的创建由其子类负责，客户端针对抽象工厂编程，可在运行时再指定具体工厂类，具体工厂类实现了工厂方法，不同的具体工厂可以创建不同的具体产品。 典型代码在工厂方法模式中，核心的工厂类不再负责所有的产品的创建，而是将具体创建的工作交给子类去做。 该核心类成为一个抽象工厂角色，仅负责给出具体工厂子类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。 允许系统在不修改具体工厂角色的情况下引进新的产品。 PPT3/79使用场景一个类不知道它所需要的对象的类；一个类通过其子类来指定创建哪个对象；将创建对象的任务委托给多个工厂子类中的某一个，客户端在使用时可以无须关心是哪一个工厂子类创建产品子类，需要时再动态指定。 例子水果农场（生产新水果，原来的农场不需要修改）、电视机工厂（增加新品牌，原来的工厂不需要修改，只要增加对应品牌的具体子工厂即可）。 优点多态性（客户代码可以做到与特定应用无关，适用于任何实体类）；基类为factory method提供缺省实现，子类可以重写新的实现，也可以继承父类的实现。 加一层间接性，增加了灵活性。 良好的封装性，代码结构清晰；扩展性好（对工厂类）；屏蔽产品类；典型的解耦框架（高层模块只需要知道产品的抽象类，其他的实现类都不需要关心）。 缺点需要Creator和相应的子类作为factory method的载体，如果应用模型确实需要creator和子类存在，则很好；否则的话，需要增加一个类层次。 相关的模式Simple factory如果只有一个具体工厂类，可以改造为Simple factory；Abstract factory经常用工厂方法来实现；Prototype不需要创建Creator的子类，但它们通常需要一个针对Product类的Initialize操作操作Template Method工厂方法经常被调用。 抽象工厂（关键词多个产品等级结构，产品族（产品等级结构），一次创建一族产品对象）抽象工厂（关键词多个产品等级结构，产品族（产品等级结构），一次创建一族产品对象）引入工厂方法中每个工厂只生产一类产品，可能导致系统中存在大量工厂类，增加系统开销。 解决办法将一些相关的产品组成一个“产品族”，由同一个工厂来统一生产。 产品族位于不同的产品等级结构中，功能相关联的产品组成的家族；每个产品族中含有产品的数目，与产品等级结构的数目相等。 产品族中的产品是不同类型本质的产品，比如电视和冰箱。 描述具体工厂实现了抽象工厂，每个具体工厂方法可返回一个特定的产品对象，而同一个具体工厂所创建的产品对象构成了一个产品族。 使用场景该系统的产品有多于一个的产品族，而系统只消费其中某一族的产品（高低硬件配置的显卡、打印驱动例子）；同属于同一产品族的产品是在一起使用的，这一约束条件必须在系统的设计中体现出来；系统提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于实现；一个对象族(或一组没有任何关系的对象)有相同的约束。 关注点分离，将对象的创建和对象的使用分离。 Client不依赖于具体工厂将实现的信息隐藏起来，使得用户不必关注实现的细节隐藏创建具体类的信息，使其对Client不可见。 优点分离了具体的类，一个工厂封装创建产品对象的责任和过程，它将客户与类的实现分离；易于交换产品系列，只需改变具体工厂就可以使用不同的产品配置；有利于产品的一致性，当一个系列中的产品对象被设计成一起工作时，一个应用一次只能使用同一个系列中的对象。 缺点难以支持新的产品等级结构（AbstractProductX），支持新的产品等级结构就要扩展抽象工厂的接口。 开闭原则增加产品族时满足开闭原则，在产品等级结构数目不变的情况下，在每一个产品等级结构中增加新的具体产品角色，在系统中加入新的具体工厂类即可；增加产品等级结构时不满足开闭，需要给每一个具体工厂类增加一个新的工厂方法。 以倾斜的方式支持增加新产品，为新产品族增加提供方便，不能为新的产品等级结构提供方便。 所有的工厂模式规则对象应该要么构造和/或管理其他对象，要么使用对象，而不应该兼而有之。 Singleton模式组合模式优点组合模式可以很容易地增加新种类的构件；使用组合模式可以使客户端变得很容易设计，因为客户端不需要知道构件是叶子还是容器对象。 缺点使用组合模式后，控制容器对象的类型就不太容易；用继承的方法增加新的行为很困难。 装饰者模式符合开闭原则引入如何应对“给一个对象，而不是整个类添加功能”，使“对象功能的扩展”能够根据需要来动态地实现。 装饰者模式中Decorator和Component之间，既有动态聚合关系又有静态继承关系。 聚合的好处是可以在运行时给对象增加职责，Decorator【HAS A】Component的目的是让ConcreteDecorator可以在运行时动态给ConcreteComponent增加职责；Decorator继承于Component的目的是统一装饰者和被装饰者的接口，即不管是ConcretComponent还是ConcreteDecorator，用户代码可以把它们统一看作Component来处理。 装饰者模式通过继承统一了装饰者和被装饰者的接口，通过聚合获得了在运行时动态扩展被装饰者对象的能力。 使用场景有一个基本功能，还有些可选功能，每一个具体的对象，在基本功能的基础上通过选用不同的可选功能来定制。 优点装饰模式与继承关系的目的都是要扩展对象的功能，但是装饰模式可以提供比继承更多的灵活性；可以通过一种动态的方式来扩展一个对象的功能；通过使用不同的具体装饰类以及这些装饰类的排列组合，可以创造出很多不同行为的组合，可以使用多个具体装饰类来装饰同一对象，得到功能更为强大的对象；具体构件类与具体装饰类可以独立变化，符合开闭原则。 缺点使用装饰模式进行系统设计时将产生很多小对象，同时还将产生很多具体装饰类；装饰模式比继承更加易于出错，排错也很困难。 相关模式区别AdapterDecorator模式中装饰仅改变对象的职责而不改变它的接口，而Adapter模式中适配器将给对象一个全新的接口；Composite可以将装饰视为一个退化的仅有一个组件的组合，Decorator的目的不在于对象聚集；Strategy用一个装饰可以改变对象的外表，而Strategy模式可以改变对象的内核。 Fa?ade模式符合单一职责原则，符合迪米特法则引入简化外部客户程序和系统间的交互接口，将外部客户程序的演化和内部子系统的变化之间的依赖相互解耦。 外部与一个子系统的通信必须通过一个统一的门面(Fa?ade)对象进行，这就是门面模式。 为子系统中的一组接口提供一个一致的界面，Fa?ade模式定义了一个高层接口，这个接口使这一子系统更加容易使用。 注意子系统并不知道Fa?ade的存在，在它看来Fa?ade只是一个client.使用场景为一个复杂子系统提供一个简单接口；提高子系统的独立性；在层次化结构中，可以使用Fa?ade模式定义系统中每一层的入口；只需要使用某个复杂系统的子集，或者，需要以一种特殊的方式与系统进行交互。 绿色斜体只理解意图即可Proxy模式引入为其他对象提供一种代理以控制对这个对象的访问。 对于每一个开销很大的对象，应该根据需要进行创建。 Template Method模板方法引入定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。 使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。 使用场景复用问题，也即许多框架结构上相似，但却在细节上稍有不同（连接不同类型数据库的例子）；约束和规则，程序中有些规则、约束我们希望不会被违反（临界资源使用的例子）。 Command模式引入如何将“行为请求者”与“行为实现者”解耦？解决办法将一组行为抽象为对象，可以实现二者之间的松耦合。 命令模式的本质是对命令进行封装，将发出命令的责任和执行命令的责任分割开，允许请求的一方和接收的一方独立开来，使得请求的一方不必知道接收请求的一方的接口。 实现要点实现Command接口的具体命令对象ConcreteCommand有时侯根据需要可能会保存一些额外的状态信息；通过使用组合模式，可以将多个“命令”封装为一个“复合命令”。 相关模式Composite模式可用来实现mand组合；为实现undo/redo，可以用其他行为模式来管理状态，如Memento模式；Command被放到history list之前，可以用Prototype模式复制自身。 Iterator模式引入提供一种方法顺序访问一个聚集对象中各个元素,而又不需暴露该对象的内部表示。 将对聚集对象的访问和遍历从聚集对象中分离出来并放入一个迭代器(iterator)将遍历机制与聚集对象分离使我们可以定义不同的迭代器来实现不同的遍历策略，而无需在聚集接口中列举它们。 说明在迭代器模式中应用了工厂方法模式，聚集类充当工厂类，而迭代器充当产品类，由于定义了抽象层，系统的扩展性很好，在客户端可以针对抽象聚集类和抽象迭代器进行编程。 Strategy策略模式符合开闭，符合里氏替换原则引入某些对象使用的算法可能多种多样，经常改变。 如何