设计模式概述

设计模式概述第1页，课件共69页，创作于2023年2月模式的起源–建筑学模式之父

—ChristopherAlexander博士—美国加利佛尼亚大学环境结构中心研究所所长《APatternLanguage:Towns,Buildings,Construction》，给出了253个建筑和城市规划模式2第2页，课件共69页，创作于2023年2月模式的定义Alexander给出了关于模式的经典定义：

每个模式都描述了一个在我们环境中不断出现的问题，然后描述了该问题的解决方案的核心，通过这种方式，我们可以无数次地重用那些已有的解决方案，无需再重复相同的工作Apatternisasolutiontoaprobleminacontext

模式是在特定环境中（前提条件下）解决目标问题的一种可重用（已确认）方案3第3页，课件共69页，创作于2023年2月模式存在的意义解决一个问题：从模式可以得到解，而不仅仅是抽象的原则或策略是一个被证明了的概念：模式通过—个记录得到解，而不是通过理论或推测解并不是显然的：对大多数比较困难的设计问题来说，以非直接的方式得到解是必要的4第4页，课件共69页，创作于2023年2月软件模式的出现1990年，软件工程界开始关注Alexander博士在建筑与城市规划领域研究的重大突破。最早将这种“模式”的思想引入软件工程方法学的以“四人组(GangofFour，GoF)自称的四位著名软件工程学者，他们在1994年归纳发表了23种在软件开发中使用频率较高的设计模式，旨在用模式来统一沟通面向对象方法在分析、设计和实现间的鸿沟5第5页，课件共69页，创作于2023年2月GoFErichGamma：苏黎世大学计算机科学博士，是Eclipse、JUnit等项目主要技术负责人之一JohnVlissides：斯坦福大学计算机科学博士，原IBM研究员RalphJohnson：康奈尔大学计算机科学博士，伊利诺伊大学教授RichardHelm：墨尔本大学计算机科学博士，原IBM研究员，现在IBM咨询集团供职6第6页，课件共69页，创作于2023年2月软件模式的概念软件模式是将模式的一般概念应用于软件开发领域，即软件开发的总体指导思路或参照样板软件模式并非仅限于设计模式，还包括架构模式、分析模式和过程模式等，实际上，在软件生存期的每一个阶段都存在着一些被认同的模式模式的核心思想是通过增加抽象层，把变化部分从那些不变部分里分离出来7第7页，课件共69页，创作于2023年2月软件模式是…对通用设计问题的重复解决方案对真实世界问题的实践的/具体的解决方案面向特定的问题环境权衡利弊之后得到的“最佳”解决方案领域专家和设计老手的“杀手锏”用文档的方式记录的最佳实践在讨论问题的解决方案时，一种可交流的词汇在使用（重用）、共享、构造软件系统中，一种有效地使用已有的智慧/经验/专家技术的方式8第8页，课件共69页，创作于2023年2月软件模式不是…仅仅限于面向对象的软件设计未经检验的想法/理论或新的发现仅仅使用过一次的解决方案（只有经过三个以上不同类型或不同领域的系统的校验，一个解决方案才能从候选模式升格为模式）以模式的形式描述过时的技术和方法抽象原理或启发性的构想在任何环境下都适用的通用解决方案“万精油”或“万能药”9第9页，课件共69页，创作于2023年2月推荐的参考书经典教材英文版经典教材中文版参考教材刘伟著参考教材入门级10第10页，课件共69页，创作于2023年2月设计模式的概念11第11页，课件共69页，创作于2023年2月软件设计中的坏味道（设计缺陷）典型表现过于僵化（Rigidity）：软件难以增加新功能，哪怕是简单的功能，存在大量的硬编码，使代码的灵活性非常差过于脆弱（Fragility）：软件的一处修改往往导致看上去没有关系的另一个地方出现故障复用率低（Immobility）：无法重用项目中其他部分的功能，只能简单的粘贴代码来代替重用粘度过高（Viscosity）：破坏系统原来框架和意图的改动方式比保留这些内容更加容易，是一种错误的代码维护方案不透明性（Opacity）：一个模块难以理解可维护性和可重用性较差12第12页，课件共69页，创作于2023年2月OOP过程中痛苦的是什么？1、选择太多，无从下手public\protected\private继承\组合实现继承\接口继承成员变量\局部变量2、没有正确答案：不知道我们是否真正的实现了面向对象的要求，看别人写的东西都是垃圾，自己写的东西慢慢也成为了垃圾问题总结为：怎样才能实现好的设计，什么才是好的设计—高可复用性，高灵活性，高扩展性—高内聚，低耦合13第13页，课件共69页，创作于2023年2月设计模式的提出背景“选择太多，无从下手”的解答：一下子得到复用性和灵活性好的设计，不可能或非常困难；所以，内行的设计者通常会复用以前使用过的可行的软件设计解决方案“没有正确答案”的解答：已经验证过、被多次使用的、面向对象的设计就是很好的设计设计模式的目的就是将面向对象软件的设计经验记录下来，可以作为面向对象软件设计的“武林秘籍”，我们掌握了设计模式，加上不断的灵活应用，就可以说是OO行家，就可以站在巨人的肩膀上作出好的设计14第14页，课件共69页，创作于2023年2月设计模式的提出背景设计模式（DesignPattern）是随着面向对象技术的出现和广泛使用而提出的在一个设计完成之前，有经验的面向对象设计师往往要重复使用若干次，而且每次都要进行改进。当然，不能只用最初的方法解决每个问题，常常重复使用那些过去用过的解决方案。而这些经验也正是他们成为专家的法宝，这就是设计经验的价值将设计面向对象软件的经验记录成“设计模式”，可以方便地重用成功的设计和结构，将已证实的技术表述成设计模式也会使新系统开发者更加容易理解其设计思路15第15页，课件共69页，创作于2023年2月设计模式的发展史1987年，KentBeck和WardCunningham借鉴Alexander的模式思想在程序开发中开始应用一些模式，在OOPSLA会议上发表了他们的成果；1990年，OOPSLA与ECOOP联合举办，ErichGamma和RichardHelm等人开始讨论有关模式的话题(BruceAnderson主持)，“四人组”正式成立，并开始着手进行设计模式的分类整理工作；1991年，OOPSLA会议上BruceAnderson主持了首次针对设计模式的研讨会，模式逐渐成为人们讨论的话题；1994年，由著名的HillsideGroup发起，在美国召开了第1届关于面向对象模式的世界性会议，名为PLoP(PatternLanguagesofPrograms,编程语言模式会议)；1995年，

四人组出版了《设计模式：可复用面向对象软件的基础》一书，成为当年最抢手的面向对象书籍，也成为设计模式的经典书籍。16第16页，课件共69页，创作于2023年2月设计模式的定义定义1：是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性定义2：是从许多优秀的软件系统中总结出的成功的可复用的设计方案，可以帮助设计者更快更好地完成系统设计定义3：是一些设计面向对象的软件开发的经验总结，一个设计模式事实上是系统地命名、解释和评价某一个重要的、可重现的面向对象的设计方案定义4：是对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述，是在类和对象的层次描述的可重复使用的软件设计问题的解决方案17第17页，课件共69页，创作于2023年2月设计模式的定义–summary设计模式是特定场景的通用设计解决方案通用被反复使用，或者已被成功实践证实过的可以复用，提高质量与效率特定场景设计模式是无穷无尽的，不同场景或者同一场景不同动机都会产生不同的设计模式可复用但勿套用，必须理解设计模式的使用场景与目标18第18页，课件共69页，创作于2023年2月设计模式的一个例子19第19页，课件共69页，创作于2023年2月需要解决什么问题？考虑一个软件应用场景，一个软件系统可以提供多个外观不同的按钮（如圆形按钮、矩形按钮、菱形按钮等），这些按钮都源自同一个基类，不过在继承基类后不同的子类修改了部分属性从而使得它们可以呈现不同的外观，怎么创建不同按钮的对象更方便呢？20第20页，课件共69页，创作于2023年2月解决方案—简单工厂模式创建这些按钮时，不需要知道这些具体按钮类的名字，只需要知道表示该按钮类的一个参数，并提供一个调用方便的方法，把该参数传入方法即可返回一个相应的按钮对象21第21页，课件共69页，创作于2023年2月应用实例—权限管理系统系统根据存储在数据库中的用户权限等级（以整数形式存储），创建不同等级的用户对象，并实现不同权限的操作22第22页，课件共69页，创作于2023年2月应用实例—权限管理系统publicabstractclassUser{ publicvoidsameOperation() {System.out.println("修改个人资料！");} publicabstractvoiddiffOperation();}publicclassManagerextendsUser{ publicEmployee() {System.out.println(“创建经理对象！");} publicvoiddiffOperation() {System.out.println(“经理拥有创建和审批假条权限！");}}23第23页，课件共69页，创作于2023年2月应用实例—权限管理系统publicclassUserFactory{ publicstaticUsergetUser(intpermission) if(0==permission) returnnewEmployee(); elseif(1==permission) returnnewManager(); elsereturnnull;}24第24页，课件共69页，创作于2023年2月应用实例—权限管理系统publicclassClient{ publicstaticvoidmain(Stringargs[]){ Useruser;intpermission=findPermission("zh","123"); user=UserFactory.getUser(permission); user.sameOperation(); user.diffOperation();}}25第25页，课件共69页，创作于2023年2月方案的评价适用场景：负责创建的对象比较少，不会造成工厂方法中的业务逻辑太过复杂；客户端只知道传入工厂类的参数，对于如何创建对象不关心优点：将对象的创建和对象本身业务处理分离，降低系统的耦合度；通常实现为类静态方法，通过类名直接调用，非常方便，而且只需要传入一个简单的参数即可缺点：简单工厂类集中了所有产品的创建逻辑，一旦不能正常工作，整个系统都要受到影响；增加了类的个数，且一旦添加新对象就得修改创建逻辑，对象较多时可能造成创建逻辑过于复杂，不利于系统的扩展和维护26第26页，课件共69页，创作于2023年2月设计模式的要素及描述方式27第27页，课件共69页，创作于2023年2月设计模式的四要素模式名称（patternname）它用一两个词来构成助记名模式的目的/问题(problem)描述了应该在何时使用模式，解释了设计问题和问题存在的前因后果，以及使用模式必须满足的一系列先决条件解决方案(solution)描述了设计的组成成分，它们之间的相互关系及各自的职责和协作方式，因为模式可应用于多种不同场合，所以解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合来解决这个问题效果(consequences)描述了应用效果及使用模式应权衡的问题（限制和约束因素）28第28页，课件共69页，创作于2023年2月设计模式的描述方式设计模式模式名和分类结构实现别名意图动机适用性协作参与者效果代码示例已知应用相关模式29第29页，课件共69页，创作于2023年2月设计模式的描述方式模式名和分类：模式名简洁地描述了设计模式的本质别名：模式的其他名称意图：设计模式是做什么的？它的基本原理和意图是什么？它解决的是什么样的特定设计问题？动机：说明一个设计问题以及如何用模式中的类、对象来解决该问题的特定情景适用性：什么情况下可以使用该设计模式？该模式可用来改进哪些不良设计？如何识别这些情况？结构：采用对象建模技术对模式中的类进行图形描述参与者：指设计模式中的类及对象以及它们各自的职责30第30页，课件共69页，创作于2023年2月设计模式的描述方式协作：模式的参与者如何协作以实现其职责实现：实现模式时需了解的一些提示、技术要点及应避免的缺陷，以及是否存在某些特定于实现语言的问题代码示例：用来说明怎样实现该模式的代码片段效果：模式如何支持其目标？使用模式的效果和所需做的权衡取舍？系统结构的哪些方面可以独立改变？已知应用：实际系统中发现的模式的例子，每个模式至少包括两个不同领域的实例相关模式：与这个模式紧密相关的模式有哪些？其不同之处是什么？这个模式应与哪些其他模式一起使用？31第31页，课件共69页，创作于2023年2月设计模式的分类32第32页，课件共69页，创作于2023年2月设计模式的分类根据模式的目的（即用来做什么）可分为：创建型模式(Creational)：主要用于创建对象结构型模式(Structural)：主要用于处理类或对象的组合行为型模式(Behavioral)：主要用于描述类或对象怎样交互

和怎样分配职责根据模式用于处理类之间还是对象之间的关系，可分为：类模式：处理类和子类之间的关系，这些关系通过继承建立，在编

译时刻就被确定下来，是属于静态的对象模式：处理对象间的关系，在运行时变化，更具有动态性33第33页，课件共69页，创作于2023年2月设计模式的分类从某种意义上说，几乎所有模式都使用继承机制，所以类模式只指那些集中于处理类间关系的模式，而大部分模式都属于对象模式的范畴创建型类模式将对象的部分创建工作延迟到子类创建型对象模式则将它延迟到另一个对象中结构型类模式使用继承机制来组合类结构型对象模式则描述了对象的组装方式行为型类模式使用继承描述算法和控制流行为型对象模式则描述一组对象怎样协作完成单个对象所无法

完成的任务34第34页，课件共69页，创作于2023年2月设计模式的分类目的创建型结构型行为型范围类FactoryMethodAdapter(类)InterpreterTemplateMethod对象AbstractFactoryBuilderPrototypeSingletonAdapter(对象)BridgeCompositeDecoratorFacadeFlyweightProxyChainofResponsibilityCommandIteratorMediatorMementoObserverStateStrategyVisitor35第35页，课件共69页，创作于2023年2月创建型设计模式示例工厂方法（FactoryMethod）：父类负责定义创建对象的公共接口，而子类则负责生成具体对象，将类的实例化操作延迟到子类中完成抽象工厂（AbstractFactory）：为一个产品族提供统一的创建接口。当需要这个产品族的某一系列的时候，可以从抽象工厂中选出相应的系列创建一个具体的工厂类单件（Singleton）：保证一个类有且仅有一个实例，提供一个全局访问点生成器（Builder）：将复杂对象创建与表示分离，同样的创建过程可创建不同的表示。允许用户通过指定复杂对象类型和内容来创建对象，用户不需要知道对象内部的具体构建细节36第36页，课件共69页，创作于2023年2月结构型设计模式示例组合（Composite）：定义一个接口，使之用于单一对象，也可以应用于多个单一对象组成的对象组装饰（Decorator）：给对象动态添加额外的职责，就好像给一个物体加上装饰物，完善其功能代理（Proxy）：在软件系统中，有些对象有时候由于跨越网络或者其他障碍，而不能够或者不想直接访问另一个对象，直接访问会给系统带来不必要的复杂性，这时候可以在客户程序和目标对象之间增加一层中间层，让代理对象来代替目标对象打点一切外观（Facade）：为子系统提供了一个更高层次、更简单的接口，从而降低了子系统的复杂度，使子系统更易于使用和管理。外观承担了子系统中类交互的责任桥梁（Bridge）：桥梁模式的用意是将问题的抽象和实现分离开来实现，通过用聚合代替继承来解决子类爆炸性增长的问题37第37页，课件共69页，创作于2023年2月行为型设计模式示例观察者（Observer）：定义了对象之间一对多的依赖，当这个对象的状态发生改变的时候，多个对象会接受到通知，有机会做出反馈命令（Command）：将请求及其参数封装成一个对象，作为命令发起者和接收者的中介，可以对这些请求排队或记录请求日志，以及支持可撤销操作策略（Strategy）：定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。策略模式使这些算法在客户端调用它们的时候能够互不影响地变化模版（Template）：定义了一个算法步骤，并允许子类为一个或多个步骤提供实现。子类在不改变算法架构的情况下，可重新定义算法中某些步骤迭代子（Iterator）：提供一种方法顺序访问一个聚合对象中各个元素,而又不需暴露该对象的内部表示38第38页，课件共69页，创作于2023年2月设计模式与软件体系结构39第39页，课件共69页，创作于2023年2月设计模式、框架、体系结构框架不等同于体系结构

体系结构确定了软件系统整体结构、层次划分，不同部分之间的协作等设计考虑；而框架比体系结构更具体，更偏重于技术。确定框架后，软件体系结构也随之确定，而对于同一体系结构（如B/S架构），可以通过多种框架（SSH等）来实现体系结构和设计模式通常出现在软件设计的不同阶段

软件架构通常出现在软件概要设计的早期；而单个设计模式不能完成一个完整的软件体系结构的详细构造，故通常用在软件详细设计阶段40第40页，课件共69页，创作于2023年2月设计模式、框架、体系结构设计模式和框架在软件设计中是两种不同的研究

框架给出的是整个应用的体系结构，而设计模式则给出单一设计问题的解决方案，并且这个方案可在不同的应用程序或者框架中进行应用；

构件通常是代码重用，而设计模式是设计重用（这个设计可被不同语言以不用方式来实现），框架则介于两者之间，部分代码重用，部分设计重用41第41页，课件共69页，创作于2023年2月设计模式的指导原则

（面向对象的设计原则）

在不改变软件现有功能的基础上，通过调整程序代码改善软件的质量和性能，使程序的设计模式和架构更趋合理，提高软件的可维护性和可重用性—重构(Refactoring)42第42页，课件共69页，创作于2023年2月设计模式的七大原则设计原则名称设计原则简介重要性单一职责原则(SRP)类的职责要单一，不能将太多的职责放在一个类中，尽量做到松耦合★★★★☆开闭原则(OCP)对扩展是开放的，对修改是关闭的，即在不修改已有程序代码的基础上去扩展其功能★★★★★里氏代换原则(LSP)在软件系统中，一个可以接受基类对象的地方必然可以接受一个子类对象★★★★☆依赖倒转原则(DIP)要针对抽象层编程，而不要针对具体类编程★★★★★接口隔离原则(ISP)使用多个专门的接口来取代一个统一的接口★★★☆☆合成复用原则(CRP)在系统中应该尽量多使用组合和聚合关联关系，尽量少使用甚至不使用继承关系★★★★☆迪米特法则(LoD)如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，而是通过引入一个第三者发生间接交互★★★☆☆43第43页，课件共69页，创作于2023年2月单一职责原则一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中，如果一个类（或者大到模块，小到方法）承担的职责越多，就相当于将这些职责功能耦合在一起，那么它被复用的可能性就越小类的职责主要包括两个方面：数据职责和行为职责，数据职责通过其属性来体现，而行为职责通过其方法来体现单一职责原则是实现高内聚、低耦合的指导方针，它是最简单但又最难运用的原则，需要设计人员具有较强的分析设计能力和相关重构经验，以分离类的不同职责44第44页，课件共69页，创作于2023年2月单一职责原则—示例45第45页，课件共69页，创作于2023年2月开闭原则软件研发过程中可以对其进行功能扩展(开放)，但并不需要对原来已有代码进行修改(关闭)，即通过不断扩展新模块满足变化的新需求，使软件系统在拥有适应性和扩展性的同时具有较好的稳定性和延续性实现的主要原则

抽象原则：利用接口、抽象类等机制定义抽象层，扩展功能时并不改动抽象层，只需要增加新的具体类来实现新功能

可变性封装原则(PrincipleofEncapsulationofVariation,EVP)：对系统所有可能发生变化的部分进行评估和分类，每一个可变的因素都单独进行封装46第46页，课件共69页，创作于2023年2月开闭原则—示例某图形界面系统提供了各种不同形状的按钮，客户端代码可针对这些按钮进行编程，用户可能会改变需求要求使用不同的按钮，如使用菱形按钮，怎么办？47第47页，课件共69页，创作于2023年2月里氏替换原则是实现开闭原则的重要方式之一如果能够使用基类对象，那么一定能够使用其子类对象。把基类都替换成它的子类，程序将不会产生任何错误和异常，反过来则不一定成立基类被真正复用，派生类能够在基类的基础上增加新的行为；在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象48第48页，课件共69页，创作于2023年2月里氏替换原则—示例对重要数据的加密处理，在DataOperator类中调用加密类(CipherA和CipherB)中实现的不同加密算法，如果更换或增加一个加密算法类时怎么办？49第49页，课件共69页，创作于2023年2月依赖倒转原则针对接口编程，不要针对实现编程——类的抽象耦合代码要依赖于抽象的类，而不要依赖于具体的类在程序代码中传递参数时或在组合聚合关系中，尽量引用层次高的抽象类，也就是使用抽象类或接口进行变量类型声明、参数类型声明、方法返回类型声明、数据类型的转换等，而不用具体的类来实现这些事情里氏替换原则是依赖倒转原则的基础（一个具体类应该只实现抽象类中声明过的方法，否则将无法调用在子类中增加的新方法），而这两者都是开闭原则的一种具体实现方法50第50页，课件共69页，创作于2023年2月依赖倒转原则—示例系统提供一个数据转换模块，可以将来自不同数据源（数据库、文本等）的数据转换成不同的显示格式（XML、XLS），那么，增加新数据源或新显示格式怎么办？51第51页，课件共69页，创作于2023年2月接口隔离原则多个和客户相关的接口要好于一个通用接口如果一个类有几个使用者，与其让这个类载入所有使用者需要使用的所有方法，还不如为不同的使用者提供宽窄不同的接口，让该类分别实现这些接口，为不同使用者提供其所需的具体方法行为使用接口隔离原则拆分接口时，首先必须满足单一职责原则，将一组相关的操作定义在一个接口中，且在满足高内聚的前提下，接口中的方法越少越好52第52页，课件共69页，创作于2023年2月接口隔离原则—示例有多个客户类的系统，定义一个AbstractService胖接口来服务所有的客户类，那么，ClientA能看到不相干的operatorB和operatorC方法，封装性差怎么办？53第53页，课件共69页，创作于2023年2月合成复用原则尽量使用对象组合，而不是继承来达到复用的目的在一个新的对象里通过关联关系（包括组合关系和聚合关系）来使用一些已有的对象，使之成为新对象的一部分；新对象通过委派调用已有对象的方法达到复用其已有功能的目的54第54页，课件共69页，创作于2023年2月继承的优缺点1.新的实现很容易，因为大部分是继承而来的2.很容易修改和扩展已有的实现1.

打破了封装，因为基类向子类暴露了实现细节2.

白盒重用，因为基类的内部细节通常对子类可见3.

当父类的实现改变时可能要相应的对子类做出改变4.

不能在运行时改变由父类继承来的实现55第55页，课件共69页，创作于2023年2月组合的优缺点1.被包含对象通过包含他们的类来访问2.黑盒重用，因为被包含对象的内部细节是不可见的3.很好的封装，每个类专注于一个任务4.通过获得和被包含对象的类型相同的对象引用，可以在运行时动态定义组合的方式1.

结果系统可能会包含更多的对象2.为了使组合时可以使用不同的对象，必须小心的定义接口56第56页，课件共69页，创作于2023年2月合成复用原则—示例如果需要更换数据库连接方式，如JDBC改为连接池，则需要修改DBUtil类源代码。如果StudentDAO采用JDBC连接，但是TeacherDAO采用连接池连接，则需要修改大量源码，违背开闭原则，系统扩展性较差57第57页，课件共69页，创作于2023年2月迪米特法则简单地说，迪米特法则就是指一个软件实体应当尽可能少的与其他实体发生相互作用。这样，当一个模块修改时，就会尽量少的影响其他的模块，扩展会相对容易，这是对软件实体之间通信的限制如果两个类之间不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，如果其中的一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用降低类之间的耦合，但是会在系统中增加大量的小方法并散落在系统的各个角落，造成系统的不同模块之间的通信效率降低58第58页，课件共69页，创作于2023年2月迪米特法则—示例某系统界面类(如Form1、Form2等类)与数据访问类(如DAO1、DAO2等类)之间的调用关系较为复杂，怎么调整会满足迪米特法则？59第59页，课件共69页，创作于2023年2月设计模式的使用方式60第60页，课件共69页，创作于2023年2月设计模式的选择—具体问题具体分析考虑设计模式是怎样解决设计问题的浏览模式的意图部分研究模式怎样相互关联研究目的相似的模式检查重新设计的原因考虑你的设计中哪些是可变的61第61页，课件共69页，创作于2023年2月设计模式的使用—循序渐进大致浏览一遍设计模式的描述，特别注意适用性和效果部分的说明，确定它适合你的问题研究模式的结构部分、参与者部分和协作部分研究代码示例部分，看看这个模式代码形式的具体例子选择模式参与者的名字，使其在应用上下文中有意义定义类定义模式中专用于应用的操作名称实现执行模式中责任和协作的操作62第62页，课件共69页，创作于2023年2月合理使用设计模式（1/3）不是软件的任何部分都需要套用模式来设计的，必须针对具体问题合理