设计模式总结范文

《设计模式总结范文》由会员分享，可在线阅读，更多相关《设计模式总结范文（16页珍藏版）》请在金锄头文库上搜索。

1、设计模式总结范文 七大设计原则单一职责原则（SRP）对于一个类，应该只有一个导致其变化的原因。 涉及模式门面、Proxy开闭原则（OCP）设计一个模块时，应该使该模块在不被修改的前提下被扩展，即可在不必修改源代码的情况下改变该模块的行为。 对扩展开放，对更改封闭。 抽象化是关键。 涉及模式Strategy,Simple Factory,Factory Method,Abstract Factory,Builder,Bridge,门面，Mediator.里氏替换原则（LSP）一个软件实体如果使用的是一个基类的话，一定适用于其子类，而且根本不能觉察出基类对象和子类对象的区别。 （在软件中如果能够使

2、用基类对象，那么一定能够使用其子类对象）尽量从抽象类继承而不从具体类继承；如果两个具体类A和B有继承关系，那么最简单的是建立一个抽象类C，让A和B成为C的子类；如果有一个由继承关系形成的等级结构，则所有树叶节点应该是具体类而所有树枝节点应该是抽象类或接口。 涉及模式Strategy,Composite,Proxy依赖倒置原则（DIP）高层模块不应该依赖低层模块，它们都应该依赖抽象。 抽象不应该依赖于细节，细节应该依赖于抽象。 针对接口编程，不要针对实现编程。 关键是以抽象方式耦合。 涉及模式Factory Method,Prototype,Iterator.接口隔离原则（ISP）使用多个专门的

3、接口比使用单一的总接口要好。 不应该强迫客户依赖于他们不用的方法；一个类的不内聚的“胖接口”应该被分解为多组方法，每一组方法都服务于一组不同的客户程序。 涉及模式Memento,Iterator.组合/聚合复用原则（CARP）尽量使用组合/聚合，而不要使用继承。 继承是类型复用，白箱复用，使得超类的细节被暴露给子类，当超类修改时，子类也被迫修改；组合/聚合可以将已有的对象纳入到新对象中，使之成为新对象的一部分，因此新对象可以调用已有对象的功能，是黑箱复用。 如果两个类是“Hasa”关系而非”Isa”关系，但设计成继承，肯定违反LSP。 迪米特法则（LoD）一个对象应该对其他对象又尽可能少的了解

4、。 （不要和陌生人说话）狭义如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。 如果其中的一个类需要调用另一个类的某一个方法，可以通过第三者转发这个调用。 广义对对象之间的信息流量、流向以及信息的影响进行控制；充分体现封装的概念。 基本原则只跟直接依赖的对象通信(不要耦合没有明显通信需求的2个对象)涉及模式门面、Mediator.GRASP核心是自己干自己能干的事，自己只干自己的事，也就是职责的分配和实现高内聚。 GRASP是对象职责分配的基本原则。 包括9个模式1)Information Expert信息专家将责任分配给信息专家，信息专家是指具有履行职责所需信息的类（实现高

5、内聚）。 信息专家模式是面向对象设计的最基本原则。 优点信息的拥有者类同时就是信息的操作者类，可以减少不必要的类之间的关联；各类的职责单一明确，容易理解。 满足了面向对象设计的封装的思想。 对应于面向对象设计原则中的单一职责原则。 2)Creator创建者谁来创建？当以下条件之一为真时，将创建类A实例的职责分配给类B B容纳A；B聚集A；B具有A的初始化数据；B记录A；B频繁使用A。 优点整个结构清晰易懂；有利于类或组件的重用；防止职责的分散；降低耦合性。 与各种工厂模式相对应（简单工厂、工厂方法、抽象工厂）3)Low coupling低耦合如何减少变化所产生的影响？责任的分配要使（不必要的）

6、耦合保持最低。 耦合主要指不同类之间相互关联的紧密程度，应该以降低类之间的耦合关系作为职责分配的原则。 4)High cohesion高内聚如何保持对象有重点、可理解和可管理，同时还要支持低耦合的作用？责任的分配要保持高内聚。 紧密相关的功能（职责）应该分配给同一个类。 低内聚的类存在难以被理解和维护，难实现类的重用，系统脆弱不断需要修改的缺点（难理解、难复用、难维护、脆弱）高内聚优点可表现关联责任的一个抽象，易于实现类的重用；使维护工作变得简单；使得系统模块化工作，方便团队工作。 模式优点聚集相关功能，结构清晰，容易理解；类的职责单一明确，降低类的复杂程度，使用简单，有利于重用；适应需求变化

7、，一旦发生变化时，可以把影响缩小到最小范围。 高内聚与低耦合模式是GRASP其他模式的根本。 5)Controller控制器Q在UI层之上第一个接受和协调（控制）系统操作的对象是哪个？（谁应该负责处理一个输入系统事件？）A将职责分配给代表一下选择之一事物对象a)代表整个“系统”、“跟对象”、运行软件的设备，或者是主要的子系统；b)代表发生该系统操作的用例场景。 （对于同一用例场景的所有系统事件使用相同的控制器类）A把接收或者处理系统事件消息的职责分配给一个类。 这个类可以代表整个系统、设备或者子系统；系统事件发生时对应的用例场景，在相同的用例场景中使用相同的控制器来处理所有的系统事件。 GRA

8、SP共识系统事件的接收与处理通常由一个高级类来代替；一个子系统会有很多控制器类，分别处理不同的事务。 正常情况下，控制器类应该把需要完成的工作委派给其他的对象。 控制器只是协调或控制这些活动，本身并不完成大量的工作。 优点提高了重用的可能性，提供了可插拔的接口它保证了接口层不处理应用逻辑；对用例的状态进行推理（保证系统操作以合法的顺序发生）。 6)Polymorphism多态GRASP扩展模式的一种。 Q当行为基于类型变化时，谁对此负责？A当相关候选者或行为基于类型（类）而变化时，使用多态操作将行为职责分配给行为所变化的类型。 也即是说尽量对抽象层编程，用多态的方法来判断具体应该使用哪个类，而

9、不是用if instanceof来判断该类是什么，执行什么。 优点易于增加新变化所需的扩展（只要实现了统一的通用接口，便可以实现行为的扩展）；无需影响客户便能够引入新的实现；避免重复代码；避免重复的分歧条件。 缺点不要为那些假想中的变化添加太多的多态。 GOF中的体现适配器、命令、组合、观察者、策略等7)Pure Fabrication纯虚构GRASP扩展模式之一把非问题域中的职责分配给人工定义的类。 原则是将非问题域的职责分配给人工生成、在业务逻辑之外加的类。 所谓问题域中的类是指从现实世界的对象抽象出来的类。 纯虚构模式是一种以功能为中心的对象或行为对象。 用于解决高内聚和低耦合之间的矛盾

10、，它要求将一部分类的职责转移到纯虚构类中。 GOF中的体现适配器、策略模式等8)Indirection间接/中介GRASP模式中解决类关联问题的模式Q如何分配职责以避免直接耦合？A将职责分配给中介对象，由该对象来协调其他构建或服务，以避免其直接耦合。 优点高内聚（通过把”关联“的功能分散到第三方类，原来的类可以更加关注自身功能的实现）；低耦合（原本关联类之间不直接关联，降低类之间的耦合性）；高重用性（第三方类对”关联“功能的集中处理，与原来的类对自身功能的专注，有利于类的重用）。 GOF中体现Fa?ade（门面）、mediator模式、代理模式、中介者模式等对应迪米特法则。 9)Protect

11、ed Variations变化预防GRASP扩展模式之一Q如何给对象、子系统和系统分配职责，以使这些元素中的变化或不稳定性不会对其他元素产生不良影响？A确定预计变化或不稳定之处，（在其外部）为其创建稳定“接口”以分配职责。 优点提高系统对变化的应对能力；高内聚；低耦合。 与开闭原则相对应。 大多数设计原则和GOF模式都是变化预防模式的体现。 GRASP小结主要特征对象职责分配的基本原则；主要应用在分析和建模上。 核心思想的理解自己干自己的事（职责的分配）；自己干自己的能干的事（职责的分配）；自己只干自己的事（职责的内聚）GOF设计模式按目的分创建型用于创建对象；结构型用于处理类或对象的组合；行

12、为型用于描述对类或对象怎样交互和怎样分配职责。 按范围分类模式处理类和子类之间的关系，属于静态；对象模式处理对象之间的关系，动态。 创建型模式对类的实例化过程进行了抽象，能够将软件模块中对象的创建和对象的使用分离。 目的就是封装对象创建的变化。 结构型模式，关注的是对象之间组合的方式。 行为型模式关注的是对象的行为，需要做的是对变化的行为进行抽象，通过封装以达到整个架构的可扩展性。 策略模式，就是将可能存在变化的策略或算法抽象为一个独立的接口或抽象类，以实现策略扩展的目的。 Command模式、State模式、Vistor模式、Iterator模式概莫如是。 或者封装一个请求（Command模

13、式），或者封装一种状态（State模式），或者封装“访问”的方式（Visitor模式），或者封装“遍历”算法（Iterator模式）。 而这些所要封装的行为，恰恰是软件架构中最不稳定的部分，其扩展的可能性也最大。 将这些行为封装起来，利用抽象的特性，就提供了扩展的可能。 创建型模式简单工厂简单工厂模式是由一个工厂类根据传入的参量决定创建出哪一种产品类的实例，涉及工厂角色(Creator)、抽象产品(Product)角色及具体产品(Concrete Product)角色等三个角色。 在简单工厂模式中，可以根据参数的不同返回不同类的实例。 简单工厂模式专门定义一个类来负责创建其他类的实例，被创建的

14、实例通常都具有共同的父类。 设计原则只在有限的程度上符合“开闭”原则。 “开闭”原则要求系统允许当新的产品加入系统时，无需对现有代码进行修改。 这一点对于产品的消费角色是成立的，而对于工厂角色不成立！适用场景工厂类负责创建的对象比较少；客户端只知道传入工厂类的参数，对于如何创建对象不关心。 工厂方法（关键特征平行等级结构）符合开闭原则，符合迪米特法则，符合依赖倒臵原则，符合里氏替换原则。 引入原因简单工厂中增加新产品时需要修改工厂类代码，违反OCP。 解决办法引入了抽象工厂角色，抽象工厂可以是接口，也可以是抽象类，将实际创建工作推迟到子类中。 典型代码抽象工厂中声明了工厂方法但并未实现工厂方法

15、，具体产品对象的创建由其子类负责，客户端针对抽象工厂编程，可在运行时再指定具体工厂类，具体工厂类实现了工厂方法，不同的具体工厂可以创建不同的具体产品。 典型代码在工厂方法模式中，核心的工厂类不再负责所有的产品的创建，而是将具体创建的工作交给子类去做。 该核心类成为一个抽象工厂角色，仅负责给出具体工厂子类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。 允许系统在不修改具体工厂角色的情况下引进新的产品。 PPT3/79使用场景一个类不知道它所需要的对象的类；一个类通过其子类来指定创建哪个对象；将创建对象的任务委托给多个工厂子类中的某一个，客户端在使用时可以无须关心是哪一个工厂子类创建产品子类，需要时再动态指定。 例子水果农场（生产新水果，原来的农场不需要修改）、电视机工厂（增加新品牌，原来的工厂不需要修改，只