【文档说明】软件工程软件设计模式与体系结构课件.ppt,共(104)页,4.374 MB,由小橙橙上传
转载请保留链接:https://www.ichengzhen.cn/view-50516.html
以下为本文档部分文字说明:
软件设计模式与体系结构面向对象设计原则概述面向对象设计原则简介常用的面向对象设计原则包括7个,这些原则并不是孤立存在的,它们相互依赖,相互补充。设计原则名称设计原则简介重要性单一职责原则SRP(Singl
eResponsibilityPrinciple)类的职责要单一,不能将太多的职责放在一个类中★★★★☆开闭原则OCP(Open-ClosedPrinciple)软件实体对扩展是开放的,但对修改是关闭的,即在不修改一个实体的基础上去扩展其功能★★★★
★里氏代换原则LSP(LiskovSubstitutionrinciple)在软件系统中,一个可以接受基类对象的地方必然可以接受一个子类对象★★★★☆依赖倒转原则DIP(DependencyInversio
nPrinciple)要针对抽象层编程,而不要针对具体类编程★★★★★接口隔离原则ISP(InterfaceSegregationPrinciple)使用多个专门的接口来取代一个统一的接口★★☆☆☆合成复用原则CRP(CompositeReusePri
nciple)在系统中应该尽量多使用组合和聚合关联关系,尽量少使用甚至不使用继承关系★★★★☆迪米特法则LoD(LawofDemeter)一个软件实体对其他实体的引用越少越好,或者说如果两个类不必彼此直接通信,那么这两个类就
不应当发生直接的相互作用,而是通过引入一个第三者发生间接交互★★★☆☆单一职责原则单一职责原则定义单一职责原则(SingleResponsibilityPrinciple,SRP)定义如下:•一个对象应该只包含单一的职责,并且该职责被完整地
封装在一个类中。其英文定义为:•Everyobjectshouldhaveasingleresponsibility,andthatresponsibilityshouldbeentirelyencapsu
latedbytheclass.另一种定义方式如下:•就一个类而言,应该仅有一个引起它变化的原因。其英文定义为:•Thereshouldneverbemorethanonereasonforaclasstochange.单一职责原则单一职责原则分析一个类(或者大到模块,小到方法)
承担的职责越多,它被复用的可能性越小,而且如果一个类承担的职责过多,就相当于将这些职责耦合在一起,当其中一个职责变化时,可能会影响其他职责的运作。类的职责主要包括两个方面:数据职责和行为职责,数据职责通过
其属性来体现,而行为职责通过其方法来体现。单一职责原则是实现高内聚、低耦合的指导方针,在很多代码重构手法中都能找到它的存在,它是最简单但又最难运用的原则,需要设计人员发现类的不同职责并将其分离,而发现类
的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。单一职责原则单一职责原则实例实例说明•某基于Java的C/S系统的“登录功能”通过如下登录类(Login)实现:•现使用单一职责原则对其进行重构。
单一职责原则单一职责原则实例实例解析开闭原则开闭原则定义变化是绝对的,但应通过扩展,而不是修改现有代码来实现开闭原则(Open-ClosedPrinciple,OCP)定义如下:•一个软件实体应当对扩
展开放,对修改关闭。也就是说在设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展,即实现在不修改源代码的情况下改变这个模块的行为。其英文定义为:•Softwareentitiesshouldbeopenf
orextension,butclosedformodification.开闭原则开闭原则分析开闭原则由BertrandMeyer于1988年提出,它是面向对象设计中最重要的原则之一。在开闭原则的定义中,软件实体可
以指一个软件模块、一个由多个类组成的局部结构或一个独立的类。开闭原则开闭原则分析抽象化是开闭原则的关键。开闭原则还可以通过一个更加具体的“对可变性封装原则”来描述,对可变性封装原则(PrincipleofEncapsulationo
fVariation,EVP)要求找到系统的可变因素并将其封装起来。需求不断变化,使系统在不断变化中保持稳定,多扩展,少修改。利用抽象,隔离变化。面向对象的核心将频繁变化的部分抽象拒绝不成熟的抽象开闭原则开闭原则实例实例说明•某图
形界面系统提供了各种不同形状的按钮,客户端代码可针对这些按钮进行编程,用户可能会改变需求要求使用不同的按钮,原始设计方案如图所示:•现对该系统进行重构,使之满足开闭原则的要求。LoginForm-button:CircleButton+display():voidCircleButton+vi
ew():voidLoginForm-button:RectangleButton+display():voidRectangleButton+view():void变化开闭原则开闭原则实例实例解析很多软件设计模式,就是为了更好的体现(实现)开闭
原则。依赖倒转原则依赖倒转原则定义依赖倒转原则(DependenceInversionPrinciple,DIP)的定义如下:•高层模块不应该依赖低层模块,它们都应该依赖抽象。•抽象不应该依赖于细节,细节应该依赖于抽象。其英
文定义为:•Highlevelmodulesshouldnotdependuponlowlevelmodules,bothshoulddependuponabstractions.Abstractionsshouldnotdependupondetails,de
tailsshoulddependuponabstractions.另一种表述为:•要针对接口编程,不要针对实现编程。其英文定义为:•Programtoaninterface,notanimplementation.依赖倒转原则依赖倒转原则分析简单来说,依赖倒转原则就是指:代码要依赖于抽象
的类,而不要依赖于具体的类;要针对接口或抽象类编程,而不是针对具体类编程。实现开闭原则的关键是抽象化,并且从抽象化导出具体化实现,如果说开闭原则是面向对象设计的目标的话,那么依赖倒转原则就是面向对象设计的主要手段。所有依赖关系,均应终止于抽象类或者接口依赖倒转原则依赖倒转原则
分析(如何实现依赖倒转?)类之间的耦合•零耦合关系•具体耦合关系•抽象耦合关系依赖倒转原则要求客户端依赖于抽象耦合,以抽象方式耦合是依赖倒转原则的关键。里氏代换原则里氏代换原则里氏代换原则定义更容易理解的定义方式:•所有引用基类(父类)的地方必须能透明地使
用其子类的对象。•或者:把所有的父类,全部替换为子类,则软件行为没有变化其英文定义为:•Functionsthatusepointersorreferencestobaseclassesmustbeabletouseobjectsofderivedclasseswit
houtknowingit.只有子类可替换掉父类,父类才可真正被复用依赖倒置原则的根本里氏代换原则里氏代换原则分析里氏代换原则是实现开闭原则的重要方式之一。由于使用基类对象的地方都可以使用子类对象,因此在程序中尽量使用基类类型来对对象进行定义
。而在运行时再确定其子类类型,用子类对象来替换父类对象。子类可替换性,使得使用父类的模块,不修改实现扩展。(引用不同的子类对象)依赖倒转原则依赖倒转原则分析依赖注入•构造注入(ConstructorInjection):通过构造函数注入
实例变量。•设值注入(SetterInjection):通过Setter方法注入实例变量。•接口注入(InterfaceInjection):通过接口方法注入实例变量。依赖倒转原则依赖倒转原则实例实例说明•某系统提供一个数据转换模块,可以将来自不
同数据源的数据转换成多种格式,如可以转换来自数据库的数据(DatabaseSource)、也可以转换来自文本文件的数据(TextSource),转换后的格式可以是XML文件(XMLTransformer)、也
可以是XLS文件(XLSTransformer)等。依赖倒转原则依赖倒转原则实例实例说明•由于需求的变化,该系统可能需要增加新的数据源或者新的文件格式,每增加一个新的类型的数据源或者新的类型的文件格式,客户类MainClass都需要修改源
代码,以便使用新的类,但违背了开闭原则。现使用依赖倒转原则对其进行重构。依赖倒转原则依赖倒转原则实例实例解析设计模式的诞生与发展模式的诞生与定义模式起源于建筑业而非软件业模式(Pattern)之父——美国加利佛尼亚大学环境结构中心研究所所长ChristopherAlex
ander博士《APatternLanguage:Towns,Buildings,Construction》——253个建筑和城市规划模式模式•Context(模式可适用的前提条件)•Theme或Problem(在特定条件下要解决的目标问题)•Solution(对目
标问题求解过程中各种物理关系的记述)设计模式的诞生与发展模式的诞生与定义Alexander给出了关于模式的经典定义:每个模式都描述了一个在我们的环境中不断出现的问题,然后描述了该问题的解决方案的核心,通过这种方式,
我们可以无数次地重用那些已有的解决方案,无需再重复相同的工作。Apatternisasolutiontoaprobleminacontext模式是在特定环境中解决问题的一种方案设计模式的诞生与发展软件模式19
90年,软件工程界开始关注ChristopherAlexander等在这一住宅、公共建筑与城市规划领域的重大突破,最早将该模式的思想引入软件工程方法学的是1991-1992年以“四人组(GangofFour,G
oF,分别是ErichGamma,RichardHelm,RalphJohnson和JohnVlissides)”自称的四位著名软件工程学者,他们在1994年归纳发表了23种在软件开发中使用频率较高的设计模式,旨在用模式来统一沟通面向对象方法在分析、设计和实
现间的鸿沟。设计模式的诞生与发展软件模式软件模式是将模式的一般概念应用于软件开发领域,即软件开发的总体指导思路或参照样板。软件模式并非仅限于设计模式,还包括架构模式、分析模式和过程模式等,实际上,在
软件生存期的每一个阶段都存在着一些被认同的模式。软件模式可以认为是对软件开发这一特定“问题”的“解法”的某种统一表示,它和Alexander所描述的模式定义完全相同,即软件模式等于一定条件下的出现的问题以及解法。软件模式的基础结构由4个部分构成:问题描述、前提条件
(环境或约束条件)、解法和效果。设计模式的定义与分类设计模式的定义设计模式(DesignPattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结,使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。设计模式的定义与分类
设计模式的基本要素设计模式一般有如下几个基本要素:模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式,其中的关键元素包括以下四个方面:•模式名称(Patternname)•问题(Problem)•解决方案(Solution)•效果(Consequenc
es)设计模式的定义与分类设计模式学习步骤按照以下次序来学习设计模式:•模式动机与定义•模式结构与分析•模式实例与解析•模式效果与应用•模式扩展设计模式的定义与分类设计模式的分类根据其目的(模式是用来做什么的)可分为创建型(C
reational),结构型(Structural)和行为型(Behavioral)三种:•创建型模式主要用于创建对象。•结构型模式主要用于处理类或对象的组合。•行为型模式主要用于描述对类或对象怎样交互和怎样分配职责。GoF设计模式简介范围\目的创建型模式结构型模式行为型模式类
模式工厂方法模式(类)适配器模式解释器模式模板方法模式对象模式抽象工厂模式建造者模式原型模式单例模式(对象)适配器模式桥接模式组合模式装饰模式外观模式享元模式代理模式职责链模式命令模式迭代器模式中介者模式备忘录模式观察者模式状态模式策略模式访问者模式创建型模式创建型模式概述创建
型模式(CreationalPattern)对类的实例化过程进行了抽象,能够将软件模块中对象的创建和对象的使用分离。为了使软件的结构更加清晰,外界对于这些对象只需要知道它们共同的接口,而不清楚其具体的实现细节,使整个系统的设计更加符合单一职责原则。创建型模式创建型模式概述创建型模式在创建什么(
What),由谁创建(Who),何时创建(When)等方面都为软件设计者提供了尽可能大的灵活性。创建型模式隐藏了类的实例的创建细节,通过隐藏对象如何被创建和组合在一起达到使整个系统独立的目的。创建型模式简单工厂模式(SimpleFactory)工厂方法模式(FactoryMe
thod)抽象工厂模式(AbstractFactory)建造者模式(Builder)原型模式(Prototype)单例模式(Singleton)创建型模式简介简单工厂模式模式动机只需要知道
水果的名字则可得到相应的水果简单工厂模式模式动机考虑一个简单的软件应用场景,一个软件系统可以提供多个外观不同的按钮(如圆形按钮、矩形按钮、菱形按钮等),这些按钮都源自同一个基类,不过在继承基类后不同的子类修改了部分属性从而使得它们
可以呈现不同的外观我们希望在使用这些按钮时,不需要知道这些具体按钮类的名字,只需要知道表示该按钮类的一个参数,并提供一个调用方便的方法,把该参数传入方法即可返回一个相应的按钮对象,此时,就可以使用简单工厂模式。简单工厂模式模式定义简单工厂模式(SimpleFactoryPat
tern):又称为静态工厂方法(StaticFactoryMethod)模式,它属于类创建型模式。在简单工厂模式中,可以根据参数的不同返回不同类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例,被创建的实例通常都具有共同的父类。可用父类引用指向对象简单工厂模式模式结构接口或抽象父类
简单工厂模式模式分析分析如下代码:publicvoidpay(Stringtype){if(type.equalsIgnoreCase("cash")){//创建先进支付的对象//现金支付处理代码}elseif(type.equalsIgnoreCase("creditcard")){
//信用卡支付处理代码(生成对象)}elseif(type.equalsIgnoreCase("voucher")){//代金券支付处理代码(生成对象)}else{……}}代码复杂,难以维护简单工厂模式模式分析重构后的代码:publicabstr
actclassAbstractPay{publicabstractvoidpay();}publicclassCashPayextendsAbstractPay{publicvoidpay(){//现金支付处理代码}}抽象支付类具体支付类简单工厂模式模式分
析重构后的代码:publicclassPayMethodFactory{publicstaticAbstractPaygetPayMethod(Stringtype){if(type.equalsIgnore
Case("cash")){returnnewCashPay();//根据参数创建具体产品}elseif(type.equalsIgnoreCase("creditcard")){returnnewCreditcardPay();//根据参数创建具体产品}……}}支付工厂简单工厂模式模式优
缺点简单工厂模式的优点•工厂类含有必要的判断逻辑,可以决定在什么时候创建哪一个产品类的实例,客户端可以免除直接创建产品对象的责任,而仅仅“消费”产品;•简单工厂模式通过这种做法实现了对责任的分割。•客户端无须知道所创建的具体产品类的类名,只需要知道具体产品类所对应的参数即可,对于一些复杂
的类名,通过简单工厂模式可以减少使用者的记忆量。•通过引入配置文件,可以在不修改任何客户端代码的情况下更换和增加新的具体产品类,在一定程度上提高了系统的灵活性。单例模式单例模式模式动机对于系统中的某些类来说,只有一个实例很重要,例如,一个系统中可以存在多个打印任务,
但是只能有一个正在工作的任务;一个系统只能有一个窗口管理器或文件系统;一个系统只能有一个计时工具或ID(序号)生成器。单例模式模式动机如何保证一个类只有一个实例并且这个实例易于被访问呢?定义一个全局变量可以确保对象随时都可以被访问,但不能防止我们实例化多个对象。一个更好的解决办法是让类自
身负责保存它的唯一实例。这个类可以保证没有其他实例被创建,并且它可以提供一个访问该实例的方法。这就是单例模式的模式动机。单例模式模式定义单例模式(SingletonPattern):单例模式确保某一个类只有一个实例,而且自行实例化并向整个系统提供这个实例,这个类称为单例类,它提供全局访问的方法
。单例模式的要点有三个:一是某个类只能有一个实例;二是它必须自行创建这个实例;三是它必须自行向整个系统提供这个实例。单例模式是一种对象创建型模式。单例模式又名单件模式或单态模式。单例模式模式结构instancei
f(instance==null)instance=newSingleton();returninstance;Singleton-instance:Singleton-+Singleton()getInstance()...:Singleton单例模式模式分析单例模式的目
的是保证一个类仅有一个实例,并提供一个访问它的全局访问点。单例模式包含的角色只有一个,就是单例类——Singleton。单例类拥有一个私有构造函数,确保用户无法通过new关键字直接实例化它。除此之外,该模式中包含一个静态私有成员变量与静态公有的工厂方法,该工厂方法负责检验实例的存在性并实例
化自己,然后存储在静态成员变量中,以确保只有一个实例被创建。单例模式模式分析单例模式的实现代码如下所示:publicclassSingleton{privatestaticSingletoninstance=nu
ll;//静态私有成员变量//私有构造函数privateSingleton(){}//静态公有工厂方法,返回唯一实例publicstaticSingletongetInstance(){if(instance==null)instanc
e=newSingleton();returninstance;}}单例模式模式分析在单例模式的实现过程中,需要注意如下三点:•单例类的构造函数为私有;•提供一个自身的静态私有成员变量;•提供一个公有的静态工厂方法。单例模式单例模式实例与解析实例一:身份
证号码•在现实生活中,居民身份证号码具有唯一性,同一个人不允许有多个身份证号码,第一次申请身份证时将给居民分配一个身份证号码,如果之后因为遗失等原因补办时,还是使用原来的身份证号码,不会产生新的号码。现使用单例模式模
拟该场景。单例模式模式优缺点单例模式的优点•提供了对唯一实例的受控访问。因为单例类封装了它的唯一实例,所以它可以严格控制客户怎样以及何时访问它,并为设计及开发团队提供了共享的概念。•由于在系统内存中只存在一个对象,因此可
以节约系统资源,对于一些需要频繁创建和销毁的对象,单例模式无疑可以提高系统的性能。•允许可变数目的实例。我们可以基于单例模式进行扩展,使用与单例控制相似的方法来获得指定个数的对象实例。单例模式模式适用环境在以下情况下可以使用单例模式:•系统只需要一个实例对象,如系
统要求提供一个唯一的序列号生成器,或者需要考虑资源消耗太大而只允许创建一个对象。•客户调用类的单个实例只允许使用一个公共访问点,除了该公共访问点,不能通过其他途径访问该实例。•在一个系统中要求一个类只有一个实例时才应当使用单例模式。反过来,如果一个类可以有几
个实例共存,就需要对单例模式进行改进,使之成为多例模式。结构型模式结构型模式简介适配器模式(Adapter)桥接模式(Bridge)组合模式(Composite)装饰模式(Decorator)外观模式(Fa
cade)享元模式(Flyweight)代理模式(Proxy)结构型模式结构型模式概述结构型模式(StructuralPattern)描述如何将类或者对象结合在一起形成更大的结构,就像搭积木,可以通过简单积木的
组合形成复杂的、功能更为强大的结构。结构型模式结构型模式概述结构型模式可以分为类结构型模式和对象结构型模式:•类结构型模式关心类的组合,由多个类可以组合成一个更大的系统,在类结构型模式中一般只存在继承关系和实现关系。•对象
结构型模式关心类与对象的组合,通过关联关系使得在一个类中定义另一个类的实例对象,然后通过该对象调用其方法。适配器模式适配器模式模式动机适配器模式模式动机在软件开发中采用类似于电源适配器的设计和编码技巧被称为适配器模式。通常情况下,客户端可以通过目标类的接口访问它所提供的服务
。有时,现有的类可以满足客户类的功能需要,但是它所提供的接口不一定是客户类所期望的,这可能是因为现有类中方法名与目标类中定义的方法名不一致等原因所导致的。在这种情况下,现有的接口需要转化为客户类期望的接口,这样保证了对现有类的重用。如果不进行这样的转化,客户类就不能利用现有类所提供的功能,适配器
模式可以完成这样的转化。适配器模式模式动机在适配器模式中可以定义一个包装类,包装不兼容接口的对象,这个包装类指的就是适配器(Adapter),它所包装的对象就是适配者(Adaptee),即被适配的类。适配器提供客户类需要的接口,适配器的实现就是把客户类的请求转化为对适配
者的相应接口的调用。也就是说:当客户类调用适配器的方法时,在适配器类的内部将调用适配者类的方法,而这个过程对客户类是透明的,客户类并不直接访问适配者类。因此,适配器可以使由于接口不兼容而不能交互的类可以
一起工作。这就是适配器模式的模式动机。适配器模式模式定义适配器模式(AdapterPattern):将一个接口转换成客户希望的另一个接口,适配器模式使接口不兼容的那些类可以一起工作,其别名为包装器(Wrapper)。适配器模式既可以作为类结构型模式,也可以作为
对象结构型模式。适配器模式模式结构适配器模式包含如下角色:•Target:目标抽象类•Adapter:适配器类•Adaptee:适配者类•Client:客户类适配器模式模式结构类适配器Adapter+request()...Target+request()..
.Adaptee+specificRequest()...ClientspecificRequest();接口实际工作的类继承自实际工作的类同时实现(符合)接口适配器模式模式结构对象适配器实例化了Adaptee对象符合要求的接口类适配器模式模式分析典型的类适配器代码
:publicclassAdapterextendsAdapteeimplementsTarget{publicvoidrequest(){specificRequest();}}适配器模式模式分析典型的对象适配器代码:publicclassAdapterextendsTarget{pri
vateAdapteeadaptee;publicAdapter(Adapteeadaptee){this.adaptee=adaptee;}publicvoidrequest(){adaptee.specificRequest();}}适配器模式适配器模式实例与解析实例一:
仿生机器人•现需要设计一个可以模拟各种动物行为的机器人,在机器人中定义了一系列方法,如机器人叫喊方法cry()、机器人移动方法move()等。如果希望在不修改已有代码的基础上使得机器人能够像狗一样叫,像狗一样跑,使用适配器模式进行系统设计。适配器模式适配器模式实例与解析实例一
:仿生机器人适配器模式适配器模式实例与解析实例二:加密适配器•某系统需要提供一个加密模块,将用户信息(如密码等机密信息)加密之后再存储在数据库中,系统已经定义好了数据库操作类。为了提高开发效率,现需要重用已有的加密算法,这些算法封装在一些由第三方提供的类中,有些甚至没有源代码
。使用适配器模式设计该加密模块,实现在不修改现有类的基础上重用第三方加密方法。练习1两相插座转化成三相插座使用适配器模式模式适用环境在以下情况下可以使用适配器模式:•系统需要使用现有的类,而这些类的接口不符合系统的需要。
•想要建立一个可以重复使用的类,用于与一些彼此之间没有太大关联的一些类,包括一些可能在将来引进的类一起工作。适配器模式模式优缺点适配器模式的优点•将目标类和适配者类解耦,通过引入一个适配器类来重用现有的适配者类,而无须修改
原有代码。•增加了类的透明性和复用性,将具体的实现封装在适配者类中,对于客户端类来说是透明的,而且提高了适配者的复用性。•灵活性和扩展性都非常好,通过使用配置文件,可以很方便地更换适配器,也可以在不修改原有代码的基础上增加新的适配器类,完全符合“开闭原则”。桥接模式模式动机12桥接模式模式结
构implClientAbstraction+operation()...Implementor+operationImpl()...RefinedAbstraction+operation()...
ConcreteImplementorA+operationImpl()...ConcreteImplementorB+operationImpl()...桥接模式桥接模式实例与解析实例二:跨平台视频播放器•如果需要开发一个跨平台视频播放器,可以在不同操作系统平台
(如Windows、Linux、Unix等)上播放多种格式的视频文件,常见的视频格式包括MPEG、RMVB、AVI、WMV等。现使用桥接模式设计该播放器。桥接模式桥接模式实例与解析实例二:跨平台视频播放
器AbstractMethodvfOperatingSystemVersion{abstract}#vf:VideoFile++setVideoFile(VideoFilevf)play(StringfileName)...:void:voidVid
eoFile+decode(StringosType,StringfileName)...:voidWindowsVersion+play(StringfileName)...:voidMPEGFile+decode(StringosType
,StringfileName)...:voidLinuxVersion+play(StringfileName):voidUnixVersion+play(StringfileName)...:voidRMVBF
ile+decode(StringosType,StringfileName)...:voidWMVFile+decode(StringosType,StringfileName)...:voidAVIFile+decode(StringosType,StringfileNam
e)...:void行为型模式行为型模式简介职责链模式(ChainofResponsibility)命令模式(Command)解释器模式(Interpreter)迭代器模式(Iterator)中介者模式(Mediator)备忘录模式(Memento)观察者模
式(Observer)状态模式(State)策略模式(Strategy)模板方法模式(TemplateMethod)访问者模式(Visitor)行为型模式行为型模式概述行为型模式(BehavioralPattern)是对在不同的对象之间划分
责任和算法的抽象化。行为型模式不仅仅关注类和对象的结构,而且重点关注它们之间的相互作用。通过行为型模式,可以更加清晰地划分类与对象的职责,并研究系统在运行时实例对象之间的交互。在系统运行时,对象并不是孤立的,它们可以通过相互通信与协作完成某些复杂功能,一个对象在运行时也将影响到其他
对象的运行。职责链模式职责链模式模式动机职责链模式模式动机职责链可以是一条直线、一个环或者一个树形结构,最常见的职责链是直线型,即沿着一条单向的链来传递请求。链上的每一个对象都是请求处理者,职责链模式可以将请求的处理者组织成一条链,并使请求沿着链传递,由
链上的处理者对请求进行相应的处理客户端无须关心请求的处理细节以及请求的传递,只需将请求发送到链上即可,将请求的发送者和请求的处理者解耦。这就是职责链模式的模式动机。职责链模式模式定义职责链模式(Cha
inofResponsibilityPattern):避免请求发送者与接收者耦合在一起,让多个对象都有可能接收请求,将这些对象连接成一条链,并且沿着这条链传递请求,直到有对象处理它为止。由于英文翻译的不同,职责链模
式又称为责任链模式,它是一种对象行为型模式。职责链模式模式结构职责链模式包含如下角色:•Handler:抽象处理者•ConcreteHandler:具体处理者•Client:客户类职责链模式模式结构successorHandler-successor:Han
dler+handleRequest()...ConcreteHandlerA+handleRequest()...ConcreteHandlerB+handleRequest()...Client后续处理类职责链模式模式分
析在职责链模式里,很多对象由每一个对象对其下家的引用而连接起来形成一条链。请求在这条链上传递,直到链上的某一个对象处理此请求为止。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求,这使得系统可以在不影响客户端的情况下动态地重新组织链和分配责任。职责链模式职责链模
式实例与解析实例:审批假条•某OA系统需要提供一个假条审批的模块,如果员工请假天数小于3天,主任可以审批该假条;如果员工请假天数大于等于3天,小于10天,经理可以审批;如果员工请假天数大于等于10天,小于30天,总经理可以审批;如果
超过30天,总经理也不能审批,提示相应的拒绝信息。职责链模式职责链模式实例与解析实例:审批假条successorLeader{abstract}##namesuccessor:String:Leader+++Leader(Stringname)setSuccessor(Leader
successor)handleRequest(LeaveRequestrequest)...:void:voidDirector++Director(Stringname)handleRequest(LeaveRequestrequest)...:v
oidLeaveRequest--leaveNameleaveDays:String:int+++++LeaveRequest(StringleaveName,intleaveDays)setLeaveName(Stringleave
Name)setLeaveDays(intleaveDays)getLeaveName()getLeaveDays()...:void:void:String:intManager++Manager(Stringname)handleRequest(LeaveRequestre
quest)...:voidGeneralManager++GeneralManager(Stringname)handleRequest(LeaveRequestrequest)...:void职责链模式模式优缺点职责链模式的优点•降低耦合度•
可简化对象的相互连接•增强给对象指派职责的灵活性•增加新的请求处理类很方便职责链模式模式适用环境在以下情况下可以使用职责链模式:•有多个对象可以处理同一个请求,具体哪个对象处理该请求由运行时刻自动确定。•在不明确指定接收者的情况下,向多个对象中的一个提交一个请求。•可动态指定一组对象处理请
求。职责链模式模式应用(1)Java中的异常处理机制try{……}catch(ArrayIndexOutOfBoundsExceptione1){……}catch(ArithmeticExceptione2){……}catch(IOExceptione3){…
…}finally{……}中介者模式中介者模式模式动机在面向对象的软件设计与开发过程中,根据“单一职责原则”,我们应该尽量将对象细化,使其只负责或呈现单一的职责。对于一个模块,可能由很多对象构成,而且这些对象之间可能存在相互的引用,为了减少对象两两之间复杂的
引用关系,使之成为一个松耦合的系统,我们需要使用中介者模式,这就是中介者模式的模式动机。中介者模式模式定义中介者模式(MediatorPattern)定义:用一个中介对象来封装一系列的对象交互,中介者
使各对象不需要显式地相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互。中介者模式又称为调停者模式,它是一种对象行为型模式。中介者模式模式分析中介者模式可以使对象之间的关系数量急剧减少:ABCDEFGIHMediatorABCDEFHIG中介者模式模式
分析中介者承担两方面的职责:•中转作用(结构性):通过中介者提供的中转作用,各个同事对象就不再需要显式引用其他同事,当需要和其他同事进行通信时,通过中介者即可。该中转作用属于中介者在结构上的支持。•协调作用(行为性):中介者可以更进一步的对同事之间的关系进行封装,同事可以一致地和中介
者进行交互,而不需要指明中介者需要具体怎么做,中介者根据封装在自身内部的协调逻辑,对同事的请求进行进一步处理,将同事成员之间的关系行为进行分离和封装。该协调作用属于中介者在行为上的支持。1..10..*chatroomAbstractChatr
oom{abstract}+++register(Membermember)sendText(Stringfrom,Stringto,Stringmessage)sendImage(Stringfrom,Stringto,Stringimage):void:voi
d:voidMember##chatroomname:AbstractChatroom:String+++++++++ChatMember(Stringname)getName()setName(Stringname)getChatroom()setChatroom(AbstractChatroo
mchatroom)sendText(Stringto,Stringmessage)sendImage(Stringto,Stringimage)receiveText(Stringfrom,Stringmessage)
receiveImage(Stringfrom,Stringimage):String:void:AbstractChatroom:void:void:void:void:voidDiamondMember+++Diamon
dMember(Stringname)sendText(Stringto,Stringmessage)sendImage(Stringto,Stringimage):void:voidCommonMember
+++CommonMember(Stringname)sendText(Stringto,Stringmessage)sendImage(Stringto,Stringimage)...:void:voi
dChatGroup-member:Hashtable+++register(Membermember)sendText(Stringfrom,Stringto,Stringmessage)sendI
mage(Stringfrom,Stringto,Stringimage):void:void:void