设计模式概述幻灯片.ppt

《设计模式概述幻灯片.ppt》由会员分享，可在线阅读，更多相关《设计模式概述幻灯片.ppt（69页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、设计模式概述第1页，共69页，编辑于2022年，星期三模式的起源 建筑学模式之父 Christopher Alexander博士 美国加利佛尼亚大学环境结构中心研究所所长A Pattern Language:Towns,Buildings,Construction，给出了253个建筑和城市规划模式2第2页，共69页，编辑于2022年，星期三模式的定义Alexander 给出了关于模式的经典定义：每个模式都描述了一个在我们环境中不断出现的问题，然后描述了该问题的解决方案的核心，通过这种方式，我们可以无数次地重用那些已有的解决方案，无需再重复相同的工作A pattern is a solution

2、 to a problem in a context 模式是在特定环境中（前提条件下）解决目标问题的一种可重用（已确认）方案 3第3页，共69页，编辑于2022年，星期三模式存在的意义解决一个问题：从模式可以得到解，而不仅仅是抽象的原则或策略是一个被证明了的概念：模式通过个记录得到解，而不是通过理论或推测解并不是显然的：对大多数比较困难的设计问题来说，以非直接的方式得到解是必要的4第4页，共69页，编辑于2022年，星期三软件模式的出现1990年，软件工程界开始关注 Alexander 博士在建筑与城市规划领域研究的重大突破。最早将这种“模式”的思想引入软件工程方法学的以“四人组(Gang o

3、f Four，GoF)自称的四位著名软件工程学者，他们在1994年归纳发表了23种在软件开发中使用频率较高的设计模式，旨在用模式来统一沟通面向对象方法在分析、设计和实现间的鸿沟5第5页，共69页，编辑于2022年，星期三GoFErich Gamma：苏黎世大学苏黎世大学计算机科学博士，是计算机科学博士，是Eclipse、JUnit 等项目主要技术负责等项目主要技术负责人之一人之一John Vlissides：斯坦福大学：斯坦福大学计算机科学博士，计算机科学博士，原原IBM研究员研究员Ralph Johnson：康奈尔大：康奈尔大学计算机科学博士，学计算机科学博士，伊利诺伊大学教授伊利诺伊大学教

4、授Richard Helm：墨尔本大：墨尔本大学计算机科学博士，原学计算机科学博士，原IBM 研究研究员，现在员，现在IBM咨询集团供职咨询集团供职6第6页，共69页，编辑于2022年，星期三软件模式的概念软件模式是将模式的一般概念应用于软件开发领域，即软件开发的总体指导思路或参照样板软件模式并非仅限于设计模式，还包括架构模式、分析模式和过程模式等，实际上，在软件生存期的每一个阶段都存在着一些被认同的模式模式的核心思想是通过增加抽象层，把变化部分从那些不变部分里分离出来7第7页，共69页，编辑于2022年，星期三软件模式是 对通用设计问题的重复解决方案对真实世界问题的实践的/具体的解决方案面向

5、特定的问题环境权衡利弊之后得到的“最佳”解决方案领域专家和设计老手的“杀手锏”用文档的方式记录的最佳实践在讨论问题的解决方案时，一种可交流的词汇在使用（重用）、共享、构造软件系统中，一种有效地使用已有的智慧/经验/专家技术的方式8第8页，共69页，编辑于2022年，星期三软件模式不是 仅仅限于面向对象的软件设计未经检验的想法/理论或新的发现仅仅使用过一次的解决方案（只有经过三个以上不同类型或不同领域的系统的校验，一个解决方案才能从候选模式升格为模式）以模式的形式描述过时的技术和方法抽象原理或启发性的构想在任何环境下都适用的通用解决方案“万精油”或“万能药”9第9页，共69页，编辑于2022年，

6、星期三推荐的参考书经典教材经典教材英文版英文版经典教材经典教材中文版中文版参考教材参考教材刘伟著刘伟著参考教材参考教材入门级入门级10第10页，共69页，编辑于2022年，星期三设计模式的概念11第11页，共69页，编辑于2022年，星期三软件设计中的坏味道（设计缺陷）典型表现过于僵化（Rigidity）：软件难以增加新功能，哪怕是简单的功能，存在大量的硬编码，使代码的灵活性非常差过于脆弱（Fragility）：软件的一处修改往往导致看上去没有关系的另一个地方出现故障复用率低（Immobility）：无法重用项目中其他部分的功能，只能简单的粘贴代码来代替重用粘度过高（Viscosity）：破坏

7、系统原来框架和意图的改动方式比保留这些内容更加容易，是一种错误的代码维护方案不透明性（Opacity）：一个模块难以理解可维护性和可重用性较差12第12页，共69页，编辑于2022年，星期三OOP过程中痛苦的是什么？1、选择太多，无从下手publicprotectedprivate继承组合实现继承接口继承成员变量局部变量2、没有正确答案：不知道我们是否真正的实现了面向对象的要求，看别人写的东西都是垃圾，自己写的东西慢慢也成为了垃圾问题总结为：怎样才能实现好的设计，什么才是好的设计 高可复用性，高灵活性，高扩展性 高内聚，低耦合13第13页，共69页，编辑于2022年，星期三设计模式的提出背景“

8、选择太多，无从下手”的解答：一下子得到复用性和灵活性好的设计，不可能或非常困难；所以，内行的设计者通常会复用以前使用过的可行的软件设计解决方案“没有正确答案”的解答：已经验证过、被多次使用的、面向对象的设计就是很好的设计设计模式的目的就是将面向对象软件的设计经验记录下来，可以作为面向对象软件设计的“武林秘籍”，我们掌握了设计模式，加上不断的灵活应用，就可以说是OO行家，就可以站在巨人的肩膀上作出好的设计14第14页，共69页，编辑于2022年，星期三设计模式的提出背景设计模式（Design Pattern）是随着面向对象技术的出现和广泛使用而提出的在一个设计完成之前，有经验的面向对象设计师往往

9、要重复使用若干次，而且每次都要进行改进。当然，不能只用最初的方法解决每个问题，常常重复使用那些过去用过的解决方案。而这些经验也正是他们成为专家的法宝，这就是设计经验的价值将设计面向对象软件的经验记录成“设计模式”，可以方便地重用成功的设计和结构，将已证实的技术表述成设计模式也会使新系统开发者更加容易理解其设计思路15第15页，共69页，编辑于2022年，星期三设计模式的发展史1987年，Kent Beck 和 Ward Cunningham 借鉴 Alexander 的模式思想在程序开发中开始应用一些模式，在OOPSLA会议上发表了他们的成果；1990年，OOPSLA与ECOOP联合举办，Er

10、ich Gamma 和 Richard Helm 等人开始讨论有关模式的话题(Bruce Anderson主持)，“四人组”正式成立，并开始着手进行设计模式的分类整理工作；1991年，OOPSLA会议上 Bruce Anderson 主持了首次针对设计模式的研讨会，模式逐渐成为人们讨论的话题；1994 年，由著名的 Hillside Group 发起，在美国召开了第1届关于面向对象模式的世界性会议，名为 PLoP(Pattern Languages of Programs,编程语言模式会议)；1995年，四人组出版了设计模式：可复用面向对象软件的基础一书，成为当年最抢手的面向对象书籍，也成为设

11、计模式的经典书籍。16第16页，共69页，编辑于2022年，星期三设计模式的定义定义1：是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性定义2：是从许多优秀的软件系统中总结出的成功的可复用的设计方案，可以帮助设计者更快更好地完成系统设计定义3：是一些设计面向对象的软件开发的经验总结，一个设计模式事实上是系统地命名、解释和评价某一个重要的、可重现的面向对象的设计方案定义4：是对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述，是在类和对象的层次描述的可重复使用的软件设计问题的解决方案17第17页，

12、共69页，编辑于2022年，星期三设计模式的定义 summary设计模式是特定场景的通用设计解决方案通用被反复使用，或者已被成功实践证实过的可以复用，提高质量与效率特定场景设计模式是无穷无尽的，不同场景或者同一场景不同动机都会产生不同的设计模式可复用但勿套用，必须理解设计模式的使用场景与目标18第18页，共69页，编辑于2022年，星期三设计模式的一个例子19第19页，共69页，编辑于2022年，星期三需要解决什么问题？考虑一个软件应用场景，一个软件系统可以提供多个外观不同的按钮（如圆形按钮、矩形按钮、菱形按钮等），这些按钮都源自同一个基类，不过在继承基类后不同的子类修改了部分属性从而使得它们

13、可以呈现不同的外观，怎么创建不同按钮的对象更方便呢？20第20页，共69页，编辑于2022年，星期三解决方案 简单工厂模式创建这些按钮时，不需要知道这些具体按钮类的名字，只需要知道表示该按钮类的一个参数，并提供一个调用方便的方法，把该参数传入方法即可返回一个相应的按钮对象21第21页，共69页，编辑于2022年，星期三应用实例 权限管理系统系统根据存储在数据库中的用户权限等级（以整数形式存储），创建不同等级的用户对象，并实现不同权限的操作22第22页，共69页，编辑于2022年，星期三应用实例 权限管理系统public abstract class User public void sameO

14、peration()System.out.println(修改个人资料！);public abstract void diffOperation();public class Manager extends User public Employee()System.out.println(“创建经理对象！);public void diffOperation()System.out.println(“经理拥有创建和审批假条权限！);23第23页，共69页，编辑于2022年，星期三应用实例 权限管理系统public class UserFactory public static User get

15、User(int permission)if(0=permission)return new Employee();else if(1=permission)return new Manager();else return null;24第24页，共69页，编辑于2022年，星期三应用实例 权限管理系统public class Client public static void main(String args)User user;int permission=findPermission(zh,123);user=UserFactory.getUser(permission);user.sa

16、meOperation();user.diffOperation();25第25页，共69页，编辑于2022年，星期三方案的评价适用场景：负责创建的对象比较少，不会造成工厂方法中的业务逻辑太过复杂；客户端只知道传入工厂类的参数，对于如何创建对象不关心优点：将对象的创建和对象本身业务处理分离，降低系统的耦合度；通常实现为类静态方法，通过类名直接调用，非常方便，而且只需要传入一个简单的参数即可缺点：简单工厂类集中了所有产品的创建逻辑，一旦不能正常工作，整个系统都要受到影响；增加了类的个数，且一旦添加新对象就得修改创建逻辑，对象较多时可能造成创建逻辑过于复杂，不利于系统的扩展和维护26第26页，共6

17、9页，编辑于2022年，星期三设计模式的要素及描述方式27第27页，共69页，编辑于2022年，星期三设计模式的四要素模式名称（pattern name）它用一两个词来构成助记名模式的目的/问题(problem)描述了应该在何时使用模式，解释了设计问题和问题存在的前因后果，以及使用模式必须满足的一系列先决条件解决方案(solution)描述了设计的组成成分，它们之间的相互关系及各自的职责和协作方式，因为模式可应用于多种不同场合，所以解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合来解决这个问题效果(consequences)描述了应用效果

18、及使用模式应权衡的问题（限制和约束因素）28第28页，共69页，编辑于2022年，星期三设计模式的描述方式设计模式模式名和分类结构实现别名意图动机适用性协作参与者效果代码示例已知应用相关模式29第29页，共69页，编辑于2022年，星期三设计模式的描述方式u模式名和分类：模式名简洁地描述了设计模式的本质u别名：模式的其他名称u意图：设计模式是做什么的？它的基本原理和意图是什么？它解决的是什么样的特定设计问题？u动机：说明一个设计问题以及如何用模式中的类、对象来解决该问题的特定情景u适用性：什么情况下可以使用该设计模式？该模式可用来改进哪些不良设计？如何识别这些情况？u结构：采用对象建模技术对模

19、式中的类进行图形描述u参与者：指设计模式中的类及对象以及它们各自的职责30第30页，共69页，编辑于2022年，星期三设计模式的描述方式u协作：模式的参与者如何协作以实现其职责u实现：实现模式时需了解的一些提示、技术要点及应避免的缺陷，以及是否存在某些特定于实现语言的问题u代码示例：用来说明怎样实现该模式的代码片段u效果：模式如何支持其目标？使用模式的效果和所需做的权衡取舍？系统结构的哪些方面可以独立改变？u已知应用：实际系统中发现的模式的例子，每个模式至少包括两个不同领域的实例u相关模式：与这个模式紧密相关的模式有哪些？其不同之处是什么？这个模式应与哪些其他模式一起使用？31第31页，共69

20、页，编辑于2022年，星期三设计模式的分类32第32页，共69页，编辑于2022年，星期三设计模式的分类根据模式的目的（即用来做什么）可分为：创建型模式(Creational)：主要用于创建对象结构型模式(Structural)：主要用于处理类或对象的组合行为型模式(Behavioral)：主要用于描述类或对象怎样交互 和怎样分配职责根据模式用于处理类之间还是对象之间的关系，可分为：类模式：处理类和子类之间的关系，这些关系通过继承建立，在编 译时刻就被确定下来，是属于静态的对象模式：处理对象间的关系，在运行时变化，更具有动态性33第33页，共69页，编辑于2022年，星期三设计模式的分类从某种

21、意义上说，几乎所有模式都使用继承机制，所以类模式只指那些集中于处理类间关系的模式，而大部分模式都属于对象模式的范畴创建型类模式 将对象的部分创建工作延迟到子类创建型对象模式 则将它延迟到另一个对象中结构型类模式 使用继承机制来组合类结构型对象模式 则描述了对象的组装方式行为型类模式 使用继承描述算法和控制流行为型对象模式 则描述一组对象怎样协作完成单个对象所无法 完成的任务34第34页，共69页，编辑于2022年，星期三设计模式的分类目的创建型结构型行为型范围类Factory MethodFactory MethodAdapter(Adapter(类类)InterpreterInterpret

22、erTemplate MethodTemplate Method对象Abstract FactoryAbstract FactoryBuilderBuilderPrototypePrototypeSingletonSingletonAdapter(Adapter(对象对象)BridgeBridgeCompositeCompositeDecoratorDecoratorFacadeFacadeFlyweightFlyweightProxyProxyChain of ResponsibilityChain of ResponsibilityCommandCommandIteratorIterato

23、rMediatorMediatorMementoMementoObserverObserverStateStateStrategyStrategyVisitorVisitor35第35页，共69页，编辑于2022年，星期三创建型设计模式示例u工厂方法（Factory Method）：父类负责定义创建对象的公共接口，而子类则负责生成具体对象，将类的实例化操作延迟到子类中完成u抽象工厂（Abstract Factory）：为一个产品族提供统一的创建接口。当需要这个产品族的某一系列的时候，可以从抽象工厂中选出相应的系列创建一个具体的工厂类u单件（Singleton）：保证一个类有且仅有一个实例，提供

24、一个全局访问点u生成器（Builder）：将复杂对象创建与表示分离，同样的创建过程可创建不同的表示。允许用户通过指定复杂对象类型和内容来创建对象，用户不需要知道对象内部的具体构建细节36第36页，共69页，编辑于2022年，星期三结构型设计模式示例u组合（Composite）：定义一个接口，使之用于单一对象，也可以应用于多个单一对象组成的对象组u装饰（Decorator）：给对象动态添加额外的职责，就好像给一个物体加上装饰物，完善其功能u代理（Proxy）：在软件系统中，有些对象有时候由于跨越网络或者其他障碍，而不能够或者不想直接访问另一个对象，直接访问会给系统带来不必要的复杂性，这时候可以在

25、客户程序和目标对象之间增加一层中间层，让代理对象来代替目标对象打点一切u外观（Facade）：为子系统提供了一个更高层次、更简单的接口，从而降低了子系统的复杂度，使子系统更易于使用和管理。外观承担了子系统中类交互的责任u桥梁（Bridge）：桥梁模式的用意是将问题的抽象和实现分离开来实现，通过用聚合代替继承来解决子类爆炸性增长的问题37第37页，共69页，编辑于2022年，星期三行为型设计模式示例u观察者（Observer）：定义了对象之间一对多的依赖，当这个对象的状态发生改变的时候，多个对象会接受到通知，有机会做出反馈u命令（Command）：将请求及其参数封装成一个对象，作为命令发起者和接

26、收者的中介，可以对这些请求排队或记录请求日志，以及支持可撤销操作u策略（Strategy）：定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。策略模式使这些算法在客户端调用它们的时候能够互不影响地变化u模版（Template）：定义了一个算法步骤，并允许子类为一个或多个步骤提供实现。子类在不改变算法架构的情况下，可重新定义算法中某些步骤u迭代子（Iterator）：提供一种方法顺序访问一个聚合对象中各个元素,而又不需暴露该对象的内部表示38第38页，共69页，编辑于2022年，星期三设计模式与软件体系结构39第39页，共69页，编辑于2022年，星期三设计模式、框架、体系结构框架不等

27、同于体系结构 体系结构确定了软件系统整体结构、层次划分，不同部分之间的协作等设计考虑；而框架比体系结构更具体，更偏重于技术。确定框架后，软件体系结构也随之确定，而对于同一体系结构（如B/S架构），可以通过多种框架（SSH等）来实现体系结构和设计模式通常出现在软件设计的不同阶段 软件架构通常出现在软件概要设计的早期；而单个设计模式不能完成一个完整的软件体系结构的详细构造，故通常用在软件详细设计阶段40第40页，共69页，编辑于2022年，星期三设计模式、框架、体系结构设计模式和框架在软件设计中是两种不同的研究 框架给出的是整个应用的体系结构，而设计模式则给出单一设计问题的解决方案，并且这个方案可

28、在不同的应用程序或者框架中进行应用；构件通常是代码重用，而设计模式是设计重用（这个设计可被不同语言以不用方式来实现），框架则介于两者之间，部分代码重用，部分设计重用41第41页，共69页，编辑于2022年，星期三 设计模式的指导原则 （面向对象的设计原则）在不改变软件现有功能的基础上，通过调整程序代码改善软件的质量和性能，使程序的设计模式和架构更趋合理，提高软件的可维护性和可重用性 重构(Refactoring)(Refactoring)42第42页，共69页，编辑于2022年，星期三设计模式的七大原则设计设计原原则则名称名称设计设计原原则简则简介介重要性重要性单单一一职责职责原原则则(SRP

29、)类类的的职责职责要要单单一，不能将太多的一，不能将太多的职责职责放在一个放在一个类类中，尽量做到松耦合中，尽量做到松耦合开开闭闭原原则则(OCP)对扩对扩展是开放的，展是开放的，对对修改是关修改是关闭闭的，即在不修的，即在不修改已有程序代改已有程序代码码的基的基础础上去上去扩扩展其功能展其功能里氏代里氏代换换原原则则(LSP)在在软软件系件系统统中，一个可以接受基中，一个可以接受基类对类对象的地方象的地方必然可以接受一个子必然可以接受一个子类对类对象象依依赖赖倒倒转转原原则则(DIP)要要针对针对抽象抽象层编层编程，而不要程，而不要针对针对具体具体类编类编程程接口隔离原接口隔离原则则(ISP

30、)使用多个使用多个专门专门的接口来取代一个的接口来取代一个统统一的接口一的接口 合成复用原合成复用原则则(CRP)在系在系统统中中应该应该尽量多使用尽量多使用组组合和聚合关合和聚合关联联关系，关系，尽量少使用甚至不使用尽量少使用甚至不使用继继承关系承关系迪米特法迪米特法则则(LoD)如果两个如果两个类类不必彼此直接通信，那么不必彼此直接通信，那么这这两个两个类类就不就不应应当当发发生直接的相互作用，而是通生直接的相互作用，而是通过过引入引入一个第三者一个第三者发发生生间间接交互接交互43第43页，共69页，编辑于2022年，星期三单一职责原则一个对象应该只包含单一的职责，并且该职责被完整地封装

31、在一个类中，如果一个类（或者大到模块，小到方法）承担的职责越多，就相当于将这些职责功能耦合在一起，那么它被复用的可能性就越小类的职责主要包括两个方面：数据职责和行为职责，数据职责通过其属性来体现，而行为职责通过其方法来体现单一职责原则是实现高内聚、低耦合的指导方针，它是最简单但又最难运用的原则，需要设计人员具有较强的分析设计能力和相关重构经验，以分离类的不同职责44第44页，共69页，编辑于2022年，星期三单一职责原则 示例45第45页，共69页，编辑于2022年，星期三开闭原则软件研发过程中可以对其进行功能扩展(开放)，但并不需要对原来已有代码进行修改(关闭)，即通过不断扩展新模块满足变化

32、的新需求，使软件系统在拥有适应性和扩展性的同时具有较好的稳定性和延续性u实现的主要原则u 抽象原则：利用接口、抽象类等机制定义抽象层，扩展功能时并不改动抽象层，只需要增加新的具体类来实现新功能u 可变性封装原则(Principle of Encapsulation of Variation,EVP)：对系统所有可能发生变化的部分进行评估和分类，每一个可变的因素都单独进行封装46第46页，共69页，编辑于2022年，星期三开闭原则 示例某图形界面系统提供了各种不同形状的按钮，客户端代码可针对这些按钮进行编程，用户可能会改变需求要求使用不同的按钮，如使用菱形按钮，怎么办？47第47页，共69页，编

33、辑于2022年，星期三里氏替换原则是实现开闭原则的重要方式之一如果能够使用基类对象，那么一定能够使用其子类对象。把基类都替换成它的子类，程序将不会产生任何错误和异常，反过来则不一定成立基类被真正复用，派生类能够在基类的基础上增加新的行为；在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象48第48页，共69页，编辑于2022年，星期三里氏替换原则 示例对重要数据的加密处理，在DataOperator 类中调用加密类(CipherA和CipherB)中实现的不同加密算法，如果更换或增加一个加密算法类时怎么办？49第49页，共69页，编辑于2022年，星

34、期三依赖倒转原则针对接口编程，不要针对实现编程 类的抽象耦合代码要依赖于抽象的类，而不要依赖于具体的类在程序代码中传递参数时或在组合聚合关系中，尽量引用层次高的抽象类，也就是使用抽象类或接口进行变量类型声明、参数类型声明、方法返回类型声明、数据类型的转换等，而不用具体的类来实现这些事情里氏替换原则是依赖倒转原则的基础（一个具体类应该只实现抽象类中声明过的方法，否则将无法调用在子类中增加的新方法），而这两者都是开闭原则的一种具体实现方法50第50页，共69页，编辑于2022年，星期三依赖倒转原则 示例系统提供一个数据转换模块，可以将来自不同数据源（数据库、文本等）的数据转换成不同的显示格式（XM

35、L、XLS），那么，增加新数据源或新显示格式怎么办？51第51页，共69页，编辑于2022年，星期三接口隔离原则多个和客户相关的接口要好于一个通用接口如果一个类有几个使用者，与其让这个类载入所有使用者需要使用的所有方法，还不如为不同的使用者提供宽窄不同的接口，让该类分别实现这些接口，为不同使用者提供其所需的具体方法行为使用接口隔离原则拆分接口时，首先必须满足单一职责原则，将一组相关的操作定义在一个接口中，且在满足高内聚的前提下，接口中的方法越少越好52第52页，共69页，编辑于2022年，星期三接口隔离原则 示例有多个客户类的系统，定义一个AbstractService胖接口来服务所有的客户类

36、，那么，ClientA能看到不相干的operatorB和operatorC方法，封装性差怎么办？53第53页，共69页，编辑于2022年，星期三合成复用原则尽量使用对象组合，而不是继承来达到复用的目的在一个新的对象里通过关联关系（包括组合关系和聚合关系）来使用一些已有的对象，使之成为新对象的一部分；新对象通过委派调用已有对象的方法达到复用其已有功能的目的54第54页，共69页，编辑于2022年，星期三继承的优缺点1.新的实现很容易，因为大部分是继承而来的 2.很容易修改和扩展已有的实现1.打破了封装，因为基类向子类暴露了实现细节 2.白盒重用，因为基类的内部细节通常对子类可见 3.当父类的实现

37、改变时可能要相应的对子类做出改变 4.不能在运行时改变由父类继承来的实现55第55页，共69页，编辑于2022年，星期三组合的优缺点1.被包含对象通过包含他们的类来访问 2.黑盒重用，因为被包含对象的内部细节是不可见的3.很好的封装，每个类专注于一个任务 4.通过获得和被包含对象的类型相同的对象引用，可以在运行时动态定义组合的方式1.结果系统可能会包含更多的对象 2.为了使组合时可以使用不同的对象，必须小心的 定义接口56第56页，共69页，编辑于2022年，星期三合成复用原则 示例如果需要更换数据库连接方式，如JDBC改为连接池，则需要修改DBUtil类源代码。如果StudentDAO采用J

38、DBC连接，但是TeacherDAO采用连接池连接，则需要修改大量源码，违背开闭原则，系统扩展性较差57第57页，共69页，编辑于2022年，星期三迪米特法则简单地说，迪米特法则就是指一个软件实体应当尽可能少的与其他实体发生相互作用。这样，当一个模块修改时，就会尽量少的影响其他的模块，扩展会相对容易，这是对软件实体之间通信的限制如果两个类之间不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，如果其中的一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用降低类之间的耦合，但是会在系统中增加大量的小方法并散落在系统的各个角落，造成系统的不同模块之间的通信效率降低58第58页，

39、共69页，编辑于2022年，星期三迪米特法则 示例某系统界面类(如Form1、Form2等类)与数据访问类(如DAO1、DAO2等类)之间的调用关系较为复杂，怎么调整会满足迪米特法则？59第59页，共69页，编辑于2022年，星期三设计模式的使用方式60第60页，共69页，编辑于2022年，星期三设计模式的选择 具体问题具体分析考虑设计模式是怎样解决设计问题的浏览模式的意图部分研究模式怎样相互关联研究目的相似的模式检查重新设计的原因考虑你的设计中哪些是可变的61第61页，共69页，编辑于2022年，星期三设计模式的使用 循序渐进大致浏览一遍设计模式的描述，特别注意适用性和效果部分的说明，确定它

40、适合你的问题研究模式的结构部分、参与者部分和协作部分研究代码示例部分，看看这个模式代码形式的具体例子选择模式参与者的名字，使其在应用上下文中有意义定义类定义模式中专用于应用的操作名称实现执行模式中责任和协作的操作62第62页，共69页，编辑于2022年，星期三合理使用设计模式（1/3）不是软件的任何部分都需要套用模式来设计的，必须针对具体问题合理的使用模式1、正确使用当设计软件系统，并确认所遇到的问题刚好适合使用某个模式，就可以考虑使用该模式到你的系统设计中，能使设计的系统易维护、可扩展性强、复用性好，而且容易让其他开发人员了解你的系统和设计思想2、避免教条设计模式不是数学公式、物理定律、更不

41、是软件设计中的法律条文，一个模式只是成功解决某个特定问题的设计方案，你完全可以修改模式中的部分结构以符合你的设计要求63第63页，共69页，编辑于2022年，星期三合理使用设计模式（2/3）3、模式挖掘模式不是用理论推导出来的，而是从真实世界的软件系统中被发现、按着一定规范总结出来的可以被复用的方案。许多文献或书籍里阐述的众多模式实际上都是GOF书中经典模式的变形，可以从领域系统中总结出新模式（经过“rule of three”认可）4、避免乱用不是所有的设计中都需要使用模式，一个设计中，可能并不需要使用模式就可以很好地满足系统的要求，如果牵强地使用某个模式可能会在系统中增加许多额外的类和对象

42、，影响系统的性能，因为大部分设计模式往往会在系统中加入更多的层，这不但增加复杂性，而且系统的效率也会下降64第64页，共69页，编辑于2022年，星期三合理使用设计模式（3/3）5、了解反模式反模式就是从某些软件系统中总结出的不好的设计方案，反模式就是告诉你如何采用一个不好的方案解决一个问题。既然是一个不好的方案，为何还有可能被重复使用呢？这是因为，这些不好的方案表面上往往有很强的吸引力，人们很难一眼就发现它的弊端，因此，发现一个反模式也是非常有意义的工作在有了一定的设计模式的基础之后，你可以用搜索引擎查找有关反模式的信息，这对于学习好设计模式也是非常有帮助的65第65页，共69页，编辑于20

43、22年，星期三设计模式的重要性66第66页，共69页，编辑于2022年，星期三设计模式的意义设计模式的目的不是针对软件设计和开发中的每个问题都给出解决方案，而是针对某种特定环境中通常都会遇到的常见问题给出可重用的一般化解决方案设计模式是从许多优秀的软件系统中总结出的成功的、能够实现可维护性复用的设计方案，使用这些方案将避免重复性工作，而且可以设计出高质量的软件系统67第67页，共69页，编辑于2022年，星期三设计模式的优点（1/2）设计模式融合了众多专家的经验，并以一种标准的形式供广大开发人员所用，它提供了一套通用的设计词汇和一种通用的语言，以方便使用不同编程语言的开发人员之间沟通和交流，使得设计方案更加通俗易懂设计模式使人们可以更加简单方便地复用成功的设计，将已证实的技术表述成设计模式也会使新系统开发者更加容易理解其设计思路，设计模式使得重用成功的设计更加容易，并避免那些导致不可重用的设计方案68第68页，共69页，编辑于2022年，星期三设计模式的优点（2/2）设计模式使得设计方案更加灵活，且易于修改设计模式将提高软件系统的开发效率和软件质量，且在一定程度上节约设计成本设计模式有助于初学者更深入地理解面向对象思想，一方面可以帮助初学者更加方便地阅读和学习现有类库与其他系统中的源代码，另一方面还可以提高软件的设计水平和代码质量69第69页，共69页，编辑于2022年，星期三