北京大学软件工程国家工程研究中心 建设概要.ppt

《北京大学软件工程国家工程研究中心 建设概要.ppt》由会员分享，可在线阅读，更多相关《北京大学软件工程国家工程研究中心 建设概要.ppt（135页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、软件体系结构(Software Architecture),讲义九：软件框架构造技术及案例分析,内 容,软件框架概述软件框架研究现状实例研究San Francisco商业开发平台,软件构造技术的发展,创造性的活动,60年代，汇编语言,结构化方法,70年代，面向功能，面向数据,面向对象方法,80年代，软件复用,基于构件方法,软件复用进一步发展,软件复用成为软件构造技术的研究热点,软件复用技术（1/2）,软件复用是提高软件生产力和质量的一种技术，将已有软件的各种有关知识用于构造新的软件，以缩短软件开发和维护的花费,代码级复用,领域知识、开发经验、体系结构、需求、设计等的复用,复用级别,软件复用技术

2、（2/2）,依据复用的组织方式个别的(Ad-hoc)复用复用在个人系统化的(Systematic)复用定义了复用过程和指南项目级别、特定领域抽象级别较高的产品复用系统化复用对于提高软件的质量和生产率具有更大的作用，也有较大的风险,软件框架概念的出现,Smalltalk-80开发环境中的框架Model-View-Controller (MVC)，被认为是第一个得到广泛应用的框架Apple Inc. User Interface Framework之后出现了一系列框架产品：Interview,ET+,Fire alarm system, (Taligent) CommonPoint, (IBM)S

3、an Francisco等等许多学者，包括Johnson, Pree, Bosch等对框架，尤其是面向对象框架展开了大量研究，包括框架设计、框架实现、框架描述、框架复用、框架演化等,软件框架的概念,软件框架的定义和描述定义1 一个框架由一组协作类组成，阐明了整个设计、类间依赖及成员类的责任分布。杨芙清，97定义2 一个框架是有意义的相互协作的类的集合，它能够同时表达针对一个特定领域实现公共的需求和设计所需要的小尺度模式和主要机制。Firesmith, 94定义3 框架是一种微体系结构，为特定领域内的软件系统提供未完全实现的模板。Jacobson, Booch, 99定义4 框架是指一个部分完成

4、的软件（子）系统，它将要被进一步实例化。框架定义了一个软件系统族的体系结构，并且提供了基本构造单元。框架同时定义了针对特定的功能，需要在哪里进行调整和修改。Buschmann, 96定义5 一个框架是一个类的集合，它体现了针对解决相关问题家族的抽象设计。Jacobson, Foot, 88定义6 一个应用框架，也称为类属应用（Generic applications），是为特定应用领域提供可复用结构的协作类集合。Gamma, 95,软件框架的概念(续),框架反映了一个领域内应用的软件体系结构，包括其组成成分、关系以及约束框架同时定义了针对特定的功能需要在哪里进行调整和修改因此，软件框架1. 提

5、供了创建具体应用的基本构造单元。2. 是一个部分完成的软件（子）系统，它将要被进一步实例化。,框架的分类,框架的分类根据应用范围分类基础设施框架：GUI框架、语言处理框架中间件集成框架：ORB框架、消息中间件企业应用框架：San Francisco根据复用方式分类白盒框架：MFC黑盒框架：Avalon项目,框架的特性部分实现,逐步实现，逐步具体化,DSSA 框架 应用,DSSA是框架的高层设计，框架是抽象应用,框架的特性“反向控制”,Hollywood Principle: Dont call us. Well call you.,框架的特性固定点和扩展点,对于面向对象框架而言，扩展点是抽象类

6、,框架特性,相关概念,领域工程框架体现了特定领域的需求，抽象了特定领域中一组应用系统的共性，因此领域分析是一种得到领域知识的较理想的方法产品线应用框架是软件产品线核心资产库的重要组成部分，框架的设计和生产属于产品线核心资产库建设的范畴构件库从软件构造的角度来讲，框架是一种大粒度的构件。框架与构件库的区别框架不仅仅是类的简单集合，而且定义了一个领域通用的高层设计构件库的结构建立于构件分类基础之上，而框架则直接反映了问题域的结构,相关概念,框架和体系结构框架决定了应用系统的体系结构一个框架可以被实例化成为多个应用系统，每个应用系统具有特定的体系结构，因此框架从框架使用的角度来看，框架和体系结构之间

7、存在着1对多(1:N)的关系从框架开发的角度来看，框架反映了一个领域的体系结构（DSSA），它是DSSA的一个实例，因此，DSSA和框架之间同样存在着1对多(1:N)的关系从在软件开发过程中所起的作用而言，体系结构是软件的高层设计抽象，它有助于系统开发团队之间的交流DSSA是可以视为“参考”体系结构，对于领域内应用系统体系结构的设计具有指导意义而开发框架最重要的目的则是针对特定领域的设计和代码复用,相关概念,应用体系结构、DSSA,Application(N),Architecture(N),DSSA(1),Framework,1,1,1,n,实例化,领域工程,n,1,n,1,相关概念,框架和

8、软件开发过程框架在整个软件开发过程中属于资产库建设的范畴，是领域设计和领域实现的重要制品之一基于框架的软件开发活动可以分为框架的设计和开发框架开发阶段基于框架定制应用系统框架使用阶段框架演化和维护阶段设计和开发一个框架成本高，但是通过复用带来的效益也更加显著框架本身是可复用资产，也有助于实现扩展部分的复用,相关概念,框架和设计模式从粒度上看，设计模式要小于框架，一个框架可以包括多个设计模式，但是设计模式不可能包括框架框架要比设计模式更加特化，框架总是与特定的应用领域相关，而通常设计模式更加普通，可以应用任何的应用领域框架的设计、实现以及描述利用了设计模式,相关概念,框架与变化性控制框架体现了领

9、域共性通过扩展点支持变化性,应用程序,框架,构件,构件,构件,构件,构件,构件,构件,领域不变部分,可变部分,内容,软件框架概念软件框架构造技术实例研究San Francisco商业开发平台,软件框架构造技术,软件框架的开发过程模型开发过程中的相关技术研究领域分析扩展点设计框架实现和测试框架的描述框架的测试和维护框架的演化白盒黑盒框架Visual Builder,框架的开发,软件框架的开发过程模型,领域分析,领域模型，DSSA，标识变化性,捕获框架需求,识别框架问题域内的扩展点和固定点,框架设计,框架SA设计，扩展点设计，固定点设计,框架实现和测试,框架文档化,应用分析,应用设计,应用实现,新

10、的需求、需求变化或更好的领域理解,框架文档,领域分析共性和变化性,当在某个领域而不是单个系统考虑问题时，就会发现一些特性是领域中所有系统共同具有的，而其它特性只是个别系统具有所有系统都具有的特性是该领域中系统的本质特性，体现为该领域中系统的共性只是部分或者个别系统具有的特性则体现为领域中系统的变化性,变化性分类,时间上的变化性和空间上的变化性时间上的变化性：产品随着时间的变化解决产品的演化问题空间上的变化性：产品家族中产品间的区别解决产品的复用问题问题域的变化性和解空间的变化性问题域的变化性主要来自于业务领域、客户、用户对领域应用系统需求的变化业务策略：实现什么功能？解空间的变化来自于系统设计

11、、实现技术、系统运行环境的变化实现机制：怎样实现功能？,变化性分类（续）,变化性模式必须的(Mandatory)需求：所有现有系统都具有这类需求可选的(Optional)需求：部分现有系统具有这类需求，并非全部系统都具有多选一的(Alternative)：只能从多个变化项选择其中一个满足需求，这些变化项存在互斥关系多选多的(Multiple Parallel Variability):这些变化性之间不存在互斥的关系，可以同时存在变化性维度组织机构、数据、功能、过程问题域实现技术解空间,扩展点（1/3）,为什么需要扩展点支持应用领域的变化性提高框架的灵活性提高框架的可复用性什么是扩展点扩展点是软

12、件框架中针对应用需求的、支持适应性变更的的扩展机制扩展点是定义良好的框架特性，可以通过特例化或者组装等扩展机制来满足特定应用的需求,扩展点OOF,面向对象框架中主要使用以下技术实现扩展功能继承组合委托参数化,扩展点OOF(续),模板方法（Template method）:定义不变流程调用钩子方法实现共性的领域知识,钩子方法（Hook method）:定义变化的部分实现特定应用的特殊需求定义为抽象方法,扩展点OOF(续),元模式,T,H,hook,1:1 Connection Pattern,T,H,hooks,1:N Connection Pattern,T,H,hook,1:1 Recurs

13、ive Connection Pattern,T,H,hooks,1:N Recursive Connection Pattern,TH,hook,1:1 Recursive Unification Pattern,TH,hook,1:N Recursive Unification Pattern,TH,Unification Pattern,扩展点CBF,构件接口调用接口定义和实现的分离支持构件功能的特定行为、算法和实现插件支持特定算法和行为的动态加载和执行构件的参数化支持构件对事件和状态变化的响应,扩展点CBF,插座插件,模板,抽象构件,外观,扩展点CBF,构件组装参数化组装：运行参数、配

14、置文件、脚本程序消息机制：消息中间件代理：桩方式、适配器、容器、Web Service机制,扩展点CBF,脚本,消息机制,Web Services,容器,小结OOF和CBF的不同,面向对象框架机制：面向对象技术的多态和继承机制复用方式：通过继承框架中的抽象类来完成特定行为的定制，白盒复用问题：框架的过度增值、脆弱的基类和隐式体系结构基于构件的框架机制：构件接口调用、构件组装等复用方式：通过一些集成机制得到对象或者构件的不同组装，来定义特定行为的，黑盒复用,框架描述语言（1/6）,框架文档必须包含的内容框架的目的明确框架针对的问题域，以及框架为问题域的哪些问题提供了解决方案如何使用框架框架得到正

15、确使用并发挥最优效果的关键所在应用实例阅读实例是理解框架主要结构的方法框架使用者可以从一组实例中看出框架的边界和不足框架的设计描述表达框架的整体体系结构和扩展点的设计细节,框架描述语言（2/6）,Cook Book途径类似“菜谱”的、一步一步讲述如何使用框架使用自然语言，举例说明框架的使用，易于理解对框架设计的描述不充分MVC Cook Book方法、 MacApp Cook Book方法、 Active Cook Book方法,框架描述语言（3/6）,模式途径主题（Motif）方法每一个主题描述一个待解决的问题，给出不同的解决方案适合描述框架如何被使用面向对象设计模式方法面向对象设计模式描述

16、了部分的面向对象设计，并不适合表达一个面向对象框架的完整设计,框架描述语言（4/6）,结构化语言途径框架描述语言（FDL）类似于C+函数说明形式化的框架实现语言以及实现模板没有给出框架的设计描述基于XML语言比较全面地给出了框架中的关键实体、实体的性质以及实体之间的关系对框架如何使用的描述不充分,框架描述语言（5/6）,UML扩展途径UML-F采用一系列布尔类型的标识值来描述面向对象框架中的三种变化点：可变方法、可扩展类和可扩展接口variable标记值表示可变方法extensible标记值表示可扩展类dynamic和static标记值分别表示运行时配置或者非运行时配置的需求appl-clas

17、s标记值表明一个类是否特定于应用incomplete用来表示可扩展接口,框架描述语言（6/6）,框架描述途径比较,框架的测试（1）,框架测试的主要目的是验证开发完成的框架是否满足领域分析阶段的需求测试活动：单元测试：针对固定点集成测试：框架是否覆盖了所针对的领域构件之间的协作是否正确框架扩展点实现是否正确 除了框架本身的测试，框架文档也是其中重要测试内容，需要验证框架文档是否正确的描述了框架扩展点,框架的测试（2）,由于框架是针对复用开发的软件制品，它并不是完整的应用系统，因此在进行测试时，需要采取以下策略：通过开发驱动模块调用框架接口，测试框架对外提供的功能在进行集成测试时，最有效的措施就是

18、在领域中选择一个有代表性的应用系统进行构造，测试基于框架能否完成目标系统，即框架的可复用性。从这个角度来看，框架的复用过程也是框架的测试过程，一个被复用多次的框架，其正确性将有显著提高,框架的维护（1）,框架维护首要的目标是通过改善框架结构，提高框架性能以及可复用性，即完善性维护，原因：框架作为一种可复用资产，内部错误比例将随着不断复用大大降低框架是针对特定领域的，其设计已经考虑了变化性，具有较高的灵活性，可以通过框架扩展以实现需求的变化,框架的维护（2）,一系列重构（Refactoring）活动有助于实现框架的完善性维护，所谓重构，是指在不改变可观察行为的前提下，对软件内部结构的改变，目的是

19、使它更易于理解并且能够更廉价地进行改变针对面向对象的软件框架，Opd92OJ93中总结了三类高层的重构方式抽象类重构：为具有一部分相同属性的类C1和C2创建一个抽象基类 子类重构：将一个复杂的类分解成几个小一点的具体类和一个表达抽象的基类 聚合类重构：识别聚积和部件,框架的演化（1/2）,应用框架的演化过程模型,框架的演化（2/2）,框架演化过程中需要考虑的问题：识别具有演化趋势的模块识别框架各版本之间改动较多的模块，这些模块应该是下一个版本中最可能被重构的模块确定框架发布的适当时间避免由于已发布的产品不符合功能和质量需求而造成的不必要的维护费用变化影响分析框架的演化对下一个版本的影响和基于前

20、一个版本开发的应用的影响，变化影响分析结果可用来预测框架演化带来的维护工作量需求管理预测增加新的需求的成本，决定是否在框架实例或新版本框架中加入新需求,框架构造原则,单一责任原则开放-封闭原则Liskov替换原则依赖倒置原则接口隔离原则,单一职责原则（SRP）,内容就一个类而言，应该仅有一个引起 它变化的原因，这条原则被称为内聚性原则。一般地，内聚性是指一个模块组成元素之间的功能相关性。 在本条原则中，把内聚性和引起一个模块或类的改变的作用联系起来。,为了理解这一原则，首先要回答什么是职责？在SRP中，把职责定义为：引起变化的理由a reason of change）。根据这一定义，显然可知：

21、如果能够想到多个（1）动机来改变一个类，那么这个类就具有多于一个的职责。实践中，人们很习惯以“组”的形式来考虑类的职责。例如： 一个接口“调制解调器”有四个功能：interface modem public void dial (string pno); public void hangup ( ); public void send (char c); public void recv ( ); ,这显然违背了SRP原则！原因是，根据职责的定义，可以认为该接口有两个职责：连接处理 public void dial (string pno); public void hangup ( );数据

22、通信 public void send (char c); public void recv ( );是否将这2个职责分离取决于应用程序变化的方式：如果应用程序的变化会影响连接函数的声明（signature）, 那么调用send和recv就必须重新编译，因此应分离这两种职责。如果应用程序的变化总是导致这两个职责同时变化，那么就不必分离这两种职责。,耦合职责的分离就上一个例子而言，可以把2个职责分离为：,其中，可以把ModemImpiementation类看作是一个杂凑物（kludge），通过分离它们的接口，解耦了概念。所有的依赖关系都与ModemImpiementation类无关。除了main

23、外，谁也不知道它的存在。,持久化问题- 左图给出了一种常见的违反该原则的情况其中，类Employee包含了业务规则和持久性控制。这2个职责在多数情况下不应该合在一起。因为业务规则往往会不断的变化，并且变化的原因也各不相同。处理：1）测试驱动的开发实践，往往会避免这种情况发生，即迫使对这2种职责进行分离。2）如果出现了这种情况，可以使用FAADE和 PROXY模式对设计进行重构，分离这2种职责。,结论SRP是最简单的一个原则，但也是最难运用的原则之一；在设计中，人们会自然地把职责合在一起；软件设计真正要做的许多内容，就是发现职责，并把这些职责相互分离。本质上，其它原则都是以这种或那种方式回答第3

24、个结论： 即分离职责。,开放-封闭原则(The Open-Closed Principle,OCP),两截门（Dutch Door）-一个被水平分割为两部分的门，这样的每一部分都可以独立保持开放或关闭。 -美国英语传统字典，第4版，2000年内容：软件实体（类、模块、函数等）应该是可扩展的，但是不可修改的。这一原则是Bertrand Meyer在1998年提出的。提出这一原则的背景之一：Ivar Jacobson曾经说过：“任何系统在其生存周期中都会 发生变化。如果期望开发的系统不会在第1版本后就被抛弃， 必须牢牢记住这一点。”,遵循这一原则开发的软件具有以下特点：“对于扩展是开放的”（ope

25、n for extention）这意味着模块的行为是可以扩展的。换言之，可以改变模 块的功能。“对于改变是封闭的”（closed for modification）这意味着对模块行为改变时，不必改动模块的源代码或 二进制代码。模块的二进制可执行版本，无论是可链接的 库、DLL或Java的.jar文件，都无需改动。,怎样才能做到看起来似乎矛盾的以上两点？关键的是抽象！不允许修改的模块，通常被认为是具有“固定”行为的模块。抽象基类以及可能的派生类，就能够描述一组任意可能行为的抽象体。模块可以操作一个抽象体。由于模块依赖一个“固定”的抽象体，因此它对于更改可以是封闭的；但通过该抽象体的派生，可以扩展

26、该模块的行为。例如，,Client,Server,Client类是既不开放又不封闭的类 （ 其中， Client 类和Server类都是具体类）,实现OCP的一种结构：,Client,interface Client Interface,Server,STRATEGY模式：既开放又封闭的Client 其中，ClientInterface类是一个拥有抽象成员的抽象类。 Client 类使用这个抽象类，但Client 类的对象却使用Server类的派生类的对象。因此，如果希望Client 对象使用一个不同的服务器类，那么只需从ClientInterface类派生一个新的类，而无需对Client 类

27、进行任何改动。Client 类需要实现一些功能，可以使用ClientInterface的抽象接口来描述这些功能。 ClientInterface的子类型可以以任何方式来实现这个接口。这样，就可以通过创建ClientInterface的新的子类型的方式来扩展、更改Client 中指定的行为。,实现OCP的另一结构：,Policy+PolicyFunction() -ServiceFunction(),Template Method模式：既开放又封闭的基类 其中，Policy类具有一组实现了某种策略的共有函数。和上图中的Client类中的函数类似，这些策略函数使用一些抽象接口描述了一些要完成的功能

28、。不同的是，在这个结构中，这些抽象接口是Policy 类的一部分。它们在C+中表现为纯虚函数，在Java中表现为抽象方法。这些函数在Policy的子类型中实现。这样，可以通过从Policy类派生出新类的方式，对Policy中指定的行为进行扩展或更改。 以上两个模式是满足OCP原则最常用的方法。应用它们，可以把一个功能的通用部分和实现细节清晰地分离开来。,结论在许多方面，开发-封闭原则（OCP）都是面向对象设计的 核心。遵循这一原则，可以带来巨大好处-灵活性、可复用 性以及可维护性。不是使用了面向对象语言就是遵循了这一原则。对应用程序中的每一部分肆意地使用抽象，同样不是一个好的主意。正确的做法是

29、，开发人员应该仅对呈现频繁变化的那些部分做出抽象。其中，“拒绝不成熟的抽象与抽象本身一样重要的”。,Liskov替换原则( LSP),在C+和Java这类语言中，支持抽象和多态的关键机制是继承（inheritance）。正是使用了继承，才可能创建实现其基类中抽象方法中的派生类。是什么设计原则支配这种特殊的继承用法？最佳的继承层次的特征是什么？怎样的情况会使创建的类层次陷入不符合OCP？ 以上正是LSP原则要回答的问题。,内容： 子类型必须能够替换掉它们的基类型。 这一原则是Barbara Liskov在1988年首先提出的。 “若对每个类型S的对象o1, 都存在一个类型T的对象o2, 使得在所

30、有针对编写的程序P中，用o1,替换o2后，程序P行为功能不变，则S是T的子类型。 ” 若违反这一原则，会出现什么后果？例如：假定有一个函数f，它的参数指向某个基类B的“指针”或“引用”。同样，假定有B的某个派生类D，如果把D的对象作为B类型传递给f，就会导致f出现错误的行为。那么D就违反了LSP。显然，D对于f来说是脆弱的。,违反 LSP，常常以违反OCP的方式使用运行时的类型辨别（RTTI）而导致的。这种方式往往是显式地使用一个if 语句或if/else来确定一个对象的类型，以便可以选择该类型的正确行为。考虑以下程序：struct Point double x,y;struct Shape

31、enum ShapeType square,circle itsType;Shape(ShapeType t):itsType ;struct Circle:public Shape Circle():Shape(Circle) ; void Draw() const; Point itsCenter; double itsRadius; ;,struct Square:public Shape Sqaure():Shape(Sqaure) ; void Draw() const; Point itsTopLeft; double itsSide; ;void DrawShape(const

32、Shape ,显然，该程序中的DrawShape函数违反了OCP它必须知道Shape类所有的派生类，且每次创建一个Shape的派生类都必须要更改它。其原因是， Square类和Circle类是Shape的派生类，具有函数Draw（）， 但没有重写（override） Shape 中的函数。由于Square类和Circle类不能替换Shape，所以DrawShape函数必须检查输入的Shape对象，确定它的类型，继之调用函数Draw（）。 Square类和Circle类不能替换Shape，这违反了LSP，从而使DrawShape违反了OCP。还有其它一些方式，可以引发违反Liskov替换原则。例

33、如：is A关系的使用-没有把子类中那些不具有多态性的函数声明为虚函数；基于契约设计的使用-派生类违反了有关基类的约定。在派生类的方法中填加了其基类不能割舍的异常,结论：LSP是使OCP成为可能的主要原因之一。正是子类型的可替换性，才使使用基类的模块在无须改变的情况下可以予以扩展。这种可替换性必须是开发人员可以隐式依赖的东西。因此如果没有显示地强制基类类型的契约，那么代码就必须良好地并显式地表达出这一点。“is-A”的含义过于宽泛，以至于不能作为子类型的定义。子类型的正确定义是“可替换性的”，这里的可替换性可以通过显式或隐式的契约予以定义。,依赖倒置原则( DIP),内容：高层模块不应该依赖低

34、层模块。二者都应该依赖抽象。抽象不应该依赖细节。细节应该依赖抽象。该原则是框架设计的核心原则层次化Booch曾经说过：“所有结构良好的面向对象构架都具有清晰的层次定义，每个层次通过一个定义良好的、受控的接口向外提供一组内聚的服务。”,对以上这句话的简单理解，可能会出现以下结构：,Policy Layer,Mechanism Layer,Utility Layer,这一结构存在一个潜伏的错误特征： （1）Policy layer对于其下一直到 Utility Layer的改动，都 是敏感的。 （2）这种依赖是可传递的。 -结论：这一结构是不好的！,合适的模型应该是：,Policy,Mechani

35、sm,Utility,Policy Layer,interfacePolicy Service Interface,Mechanism Layer,interface Mechanism Service Interface,Utility Layer,每个较高层次为它所需要的服务声明一个抽象接口，较低层次实现这些抽象接口；每个较高层次都通过抽象接口使用下一层。这样1）高层就不依赖低层，而低层则依赖高层；2）不仅解除了其中的传递依赖关系，而且还解除了高层与其它层的依赖关系。,倒置的接口所有权问题这就是著名的Hollywood 原则“Dont call us, well call you.”即低层

36、模块实现了在高层模块中声明并被高层模块调用的接口。依赖于抽象这是解释DIP规则的一个启发式规则。该规则建议不应该依赖具体类-即程序中的所有依赖关系都应该终止于抽象类或接口。根据这个启发式规则，可知：任何变量都不应该持有一个指向具体类的指针或引用；任何类都不应该从具体类派生；任何方法都不应该覆写它的任何基类中已实现的方法。,注意：在编程中，有时必须要创建具体类的实例，而创建这些实例的模块将会依赖它们。这说明程序中一般都会出现违反启发式规则的情况。如果一个具体类不太会改变，且不会创建其它类似的派生类，那么依赖它也不会造成损害。这说明对那些稳定的具体类而言，启发式规则似乎不大合理。如果具体类是不稳定

37、的，且还不想直接依赖之，则可以把它们隐藏在抽象接口之后，以隔离它们的不稳定性。依赖倒置规则可应用于任何存在一个类向另一个类发送消息的地方。,违反依赖倒置原则的例子：,这是一个以Button控制Lamp的系统。其中，Button类直接依赖Lamp对象，这个设计不能让Button控制其它设备。该设计方案就违反了DIP，即应用程序的高层策略没有与低层策略相分离，自然使抽象依赖于具体细节。其对应的Java如左所示。,什么是高层策略？它是应用的抽象，是那些不随具体细节而改变的“真理”。它是系统内部的系统-隐喻(metaphore),Lamp,通过倒置对Lamp的依赖关系，可以形成以上的设计。 其中，由接

38、口ButtonServer提供一些抽象方法，Button可以使用这些方法对有关设备进行控制。由Lamp来实现接口ButtonServer。 这样的设计就具有很好的灵活性。但问题是Lamp可能还受其他类的控制。但由于Lamp实现了接口ButtonServer，所以就做不到这一点。,结论：使用传统的过程化设计所创建的依赖关系结构，策略是依赖于细节的。这样会使策略受到细节改变的影响。面向对象程序设计倒置了依赖关系的结构，是策略和细节都依赖抽象，并且通常是客户的服务接口。这种依赖关系的倒置，正好是面向对象的标志所在。依赖倒置原则是实现许多面向对象技术所宣称的那些益处的低层机制。它的正确应用对创建可复用

39、的框架是必须的。同时对建造具有弹性的代码（应对变化）是非常重要的。应用该原则可以做到抽象和细节彼此分离，因此代码也易于维护。,接口隔离原则( ISP ),内容：不应强迫客户（client）依赖它们不用的方法。解决的问题：ISP原则用来处理“胖接口”所带来的缺点。何谓胖接口？如果类的接口不是内聚的，则称该接口是胖接口。换言之，类的胖接口可以分解为多组方法，每一组方法服务于一组不同客户程序。接口污染问题考虑一个安全系统。其中有一些Door对象，可以加锁和解锁，并且知道自己所处的状态（开/关）。,class Door public: virtual void Lock()=0; virtual vo

40、id UnLock()=0; virtual bool IsDoorOpen()=0; 显然，这是一个抽象类。客户程序可以使用符合Door的那些接口对象，而不依赖Door的特定实现。 现在考虑这样一个实现-TimedDoor.其中，如果门开着的时间过长，就会发出警报。为此， TimedDoor对象需要和一个名为Timer的对象进行交互。即如果希望得到超时时间，就可以调用Timer的Register函数,该函数有2个参数：一个是超时时间，另一个是TimerClient对象的指针，该对象的TimeOut函数会在达到超时时予以调用。,现在的问题是，如何建立类TimerClient和类TimedDoo

41、r之间的关联，才能在超时时通知TimedDoor中相应的处理代码？下面给出了一种可想到的方案：,Timer,Door,TimedDoor,0.*,其中，Door继承了Timer Client，因此TimedDoor也继承了Timer Client，这就可以保证TimerClient把自己注册到Timer中，并可接收TimeOut的消息。,现在的问题是，如何建立类TimerClient和类TimedDoor之间的关联，才能在超时时通知TimedDoor中相应的处理代码？下面给出了一种可想到的方案：,Timer,Interface Timer Client+Timeout,Door,TimedDo

42、or,0.*,其中，Door继承了Timer Client，因此TimedDoor也继承了Timer Client，这就可以保证TimerClient把自己注册到Timer中，并可接收TimeOut的消息。,现在,类Door依赖于TimerClient。该方案的主要问题就出现在这里。 1）不是所有种类的Door都需要定时功能。最初的Door与定时功能没有任何关系，如果需要创建一个没有定时功能的派生类，那么就必须要提供TimeOut方法的“退化”实现，这就违反了接口分离原则。 2）另外，使用这些派生类的应用程序，即使不使用定义的TimerClient，也必须引入之，因此就具有不必要的复杂性和不必

43、要的重复-“臭味”。,这是一个接口污染问题： 1）Door的接口被一个它不需要的方法污染了-在Door的接口中加入这个方法只是为了给它的子类带来好处。 2）如果这样持续下去的话，每一次子类需要一个新方法时，就被加入到基类中，这样就可能进一步污染了接口，使它“胖”了起来。,3、实现分离接口的途径 1）分离客户（程序）就是分离接口 Door的接口和TimerClient的接口完全被不同的客户程序所使用，即Timer使用TimerClient，而对Door的操作使用了类Door。 既然客户程序是分离的，所以接口也应该保持分离。原因是客户程序对它们使用的接口是有影响的。,2）使用委托 分离接口 创建一

44、个由TimerClient 所派生的对象，并把该对象的请求委托给TimedDoor.,Timer,Interface Timer Client+Timeout,Door,TimedDoor+DoorTimeOut,0.*,Door Timer Adapter+Timeout(),creates,其中,当TimedDoor想要向Timer对象注册一个超时请求时,它就创建一个DoorTimerAdapter,并把它注册给Timer.当Timer对象发送Timeout消息给DoorTimerAdapter时, DoorTimerAdapter把这个消息委托给TimedDoor.,对这一方案的分析:

45、1) 该方案遵循了ISP,并避免了Door的客户程序和之间的耦合. 2)即使对Timer的进行了修改,也不会影响Door的使用者. 其中Timer的定义如下: Class Timer public: void Register(int timeout,int timeoutID,TimeCclient* client); ; Class TimerClient public: virtual void TimeOut( int timeoutID)=0; ;,3) Timed Door也不必具有和 TimerClient一样的接口;4) DoorTimerAdapter会将TimerClien

46、t接口转换为TimedDoor 接口. 因此，这是一个非常通用的解决方案。5) 该方案尽管是一种通用的,但不是很优雅的.即每次想去注 册一个超时请求时,都要创建一个新的对象.这对于那些对 内存和运行时间要求高的系统而言,例如嵌入式实时系统, 就显得不够理想。,3）使用多继承 分离接口下图给出使用多继承并达到遵循ISP的方案:,Timer,Interface Timer Client+Timeout,Door,TimedDoor +DoorTimeOut,0.*,其中,在这个模型中, TimedDoor同时继承了Door和TimerClient.这样,尽管这2个基类的客户程序都可以使用TimedDoor,但在实际上却都不再依赖TimedDoor.从而,它们就通过分离的接口使用同一对象.,比较: 就这一问题的2),3)方案而言, 只有当Door Timer Adapter对象所做的转换是必须的,或不同时候回需要不同转换时,才会选择2)中给出的方案.,