北京大学软件工程国家工程研究中心建设概要kxf.pptx
软件体系结构软件体系结构(Software Architecture)讲义九：软件框架构造技术及案例分析讲义九：软件框架构造技术及案例分析内内 容容1.软件框架概述2.软件框架研究现状3.实例研究SanFrancisco商业开发平台软件构造技术的发展软件构造技术的发展创造性的活动创造性的活动60年代，汇编语言结构化方法结构化方法70年代，面向功能，面向数据面向对象方法面向对象方法80年代，软件复用基于构件方法基于构件方法软件复用进一步发展软件复用成为软件构造技术的研究热点软件复用成为软件构造技术的研究热点软件复用技术（软件复用技术（1/2）软件复用是提高软件生产力和质量的一种技术，将已有软件的各种有关知识用于构造新的软件，以缩短软件开发和维护的花费代码级复用领域知识、开发经验、体系结构、需求、设计等的复用复用级别软件复用技术（软件复用技术（2/2）依据复用的组织方式个别的(Ad-hoc)复用复用在个人系统化的(Systematic)复用定义了复用过程和指南项目级别、特定领域抽象级别较高的产品复用系统化复用对于提高软件的质量和生产率具有更大的作用，也有较大的风险软件框架概念的出现软件框架概念的出现Smalltalk-80开发环境中的框架Model-View-Controller(MVC)，被认为是第一个得到广泛应用的框架AppleInc.UserInterfaceFramework之后出现了一系列框架产品：Interview,ET+,Firealarmsystem,(Taligent)CommonPoint,(IBM)SanFrancisco等等许多学者，包括Johnson,Pree,Bosch等对框架，尤其是面向对象框架展开了大量研究，包括框架设计、框架实现、框架描述、框架复用、框架演化等软件框架的概念软件框架的概念软件框架的定义和描述定义1一个框架由一组协作类组成，阐明了整个设计、类间依赖及成员类的责任分布。杨芙清，97定义2一个框架是有意义的相互协作的类的集合，它能够同时表达针对一个特定领域实现公共的需求和设计所需要的小尺度模式和主要机制。Firesmith,94定义3框架是一种微体系结构，为特定领域内的软件系统提供未完全实现的模板。Jacobson,Booch,99定义4框架是指一个部分完成的软件（子）系统，它将要被进一步实例化。框架定义了一个软件系统族的体系结构，并且提供了基本构造单元。框架同时定义了针对特定的功能，需要在哪里进行调整和修改。Buschmann,96定义5一个框架是一个类的集合，它体现了针对解决相关问题家族的抽象设计。Jacobson,Foot,88定义6一个应用框架，也称为类属应用（Genericapplications），是为特定应用领域提供可复用结构的协作类集合。Gamma,95软件框架的概念软件框架的概念(续续)框架反映了一个领域内应用的软件体系结构，包括其组成成分、关系以及约束框架同时定义了针对特定的功能需要在哪里进行调整和修改因此，软件框架1.提供了创建具体应用的基本构造单元。2.是一个部分完成的软件（子）系统，它将要被进一步实例化。框架的分类框架的分类框架的分类根据应用范围分类基础设施框架：GUI框架、语言处理框架中间件集成框架：ORB框架、消息中间件企业应用框架：SanFrancisco根据复用方式分类白盒框架：MFC黑盒框架：Avalon项目框架的特性框架的特性部分实现部分实现逐步实现，逐步具体化DSSA框架 应用DSSA是框架的高层设计，框架是抽象应用是框架的高层设计，框架是抽象应用框架的特性框架的特性“反向控制反向控制”Hollywood Principle:Dont call us.Well call you.框架的特性框架的特性固定点和扩展点固定点和扩展点对于面向对象框对于面向对象框架而言，扩展点架而言，扩展点是抽象类是抽象类框架特性框架特性相关概念相关概念领域工程框架体现了特定领域的需求，抽象了特定领域中一组应用系统的共性，因此领域分析是一种得到领域知识的较理想的方法产品线应用框架是软件产品线核心资产库的重要组成部分，框架的设计和生产属于产品线核心资产库建设的范畴构件库从软件构造的角度来讲，框架是一种大粒度的构件。框架与构件库的区别框架不仅仅是类的简单集合，而且定义了一个领域通用的高层设计构件库的结构建立于构件分类基础之上，而框架则直接反映了问题域的结构相关概念相关概念框架和体系结构框架决定了应用系统的体系结构一个框架可以被实例化成为多个应用系统，每个应用系统具有特定的体系结构，因此框架从框架使用的角度来看，框架和体系结构之间存在着1对多(1:N)的关系从框架开发的角度来看，框架反映了一个领域的体系结构（DSSA），它是DSSA的一个实例，因此，DSSA和框架之间同样存在着1对多(1:N)的关系从在软件开发过程中所起的作用而言，体系结构是软件的高层设计抽象，它有助于系统开发团队之间的交流DSSA是可以视为“参考”体系结构，对于领域内应用系统体系结构的设计具有指导意义而开发框架最重要的目的则是针对特定领域的设计和代码复用相关概念相关概念应用体系结构、DSSAApplication(N)Architecture(N)DSSA(1)Framework111n实例化领域工程n1n1相关概念相关概念框架和软件开发过程框架在整个软件开发过程中属于资产库建设的范畴，是领域设计和领域实现的重要制品之一基于框架的软件开发活动可以分为框架的设计和开发框架开发阶段基于框架定制应用系统框架使用阶段框架演化和维护阶段设计和开发一个框架成本高，但是通过复用带来的效益也更加显著框架本身是可复用资产，也有助于实现扩展部分的复用相关概念相关概念框架和设计模式从粒度上看，设计模式要小于框架，一个框架可以包括多个设计模式，但是设计模式不可能包括框架框架要比设计模式更加特化，框架总是与特定的应用领域相关，而通常设计模式更加普通，可以应用任何的应用领域框架的设计、实现以及描述利用了设计模式相关概念相关概念框架与变化性控制框架体现了领域共性通过扩展点支持变化性应用程序框架构件构件构件构件构件构件构件领域不变部分可变部分内容内容1.软件框架概念2.软件框架构造技术3.实例研究SanFrancisco商业开发平台软件框架构造技术软件框架构造技术软件框架的开发过程模型开发过程中的相关技术研究领域分析扩展点设计框架实现和测试框架的描述框架的测试和维护框架的演化白盒黑盒框架VisualBuilder框架的开发框架的开发软件框架的开发过程模型领域分析领域模型，DSSA，标识变化性捕获框架需求识别框架问题域内的扩展点和固定点框架设计框架SA设计，扩展点设计，固定点设计框架实现和测试框架文档化应用分析应用设计应用实现新的需求、需求变化或更好的领域理解框架文档框架文档领域分析领域分析共性和变化性共性和变化性当在某个领域而不是单个系统考虑问题时，就会发现一些特性是领域中所有系统共同具有的，而其它特性只是个别系统具有所有系统都具有的特性是该领域中系统的本质特性，体现为该领域中系统的共性只是部分或者个别系统具有的特性则体现为领域中系统的变化性变化性分类变化性分类时间上的变化性和空间上的变化性时间上的变化性：产品随着时间的变化解决产品的演化问题空间上的变化性：产品家族中产品间的区别解决产品的复用问题问题域的变化性和解空间的变化性问题域的变化性主要来自于业务领域、客户、用户对领域应用系统需求的变化业务策略：实现什么功能？解空间的变化来自于系统设计、实现技术、系统运行环境的变化实现机制：怎样实现功能？变化性分类（续）变化性分类（续）变化性模式必须的(Mandatory)需求：所有现有系统都具有这类需求可选的(Optional)需求：部分现有系统具有这类需求，并非全部系统都具有多选一的(Alternative)：只能从多个变化项选择其中一个满足需求，这些变化项存在互斥关系多选多的(MultipleParallelVariability):这些变化性之间不存在互斥的关系，可以同时存在变化性维度组织机构、数据、功能、过程问题域实现技术解空间扩展点（扩展点（1/3）为什么需要扩展点支持应用领域的变化性提高框架的灵活性提高框架的可复用性什么是扩展点扩展点是软件框架中针对应用需求的、支持适应性变更的的扩展机制扩展点是定义良好的框架特性，可以通过特例化或者组装等扩展机制来满足特定应用的需求扩展点扩展点OOF面向对象框架中主要使用以下技术实现扩展功能继承组合委托参数化扩展点扩展点OOF(续续)模板方法（Templatemethod）:定义不变流程调用钩子方法实现共性的领域知识钩子方法（Hookmethod）:定义变化的部分实现特定应用的特殊需求定义为抽象方法扩展点扩展点OOF(续续)元模式THhook1:1 Connection PatternTHhooks1:N Connection PatternTHhook1:1 Recursive Connection PatternTHhooks1:N Recursive Connection PatternTHhook1:1 Recursive Unification PatternTHhook1:N Recursive Unification PatternTHUnification Pattern扩展点扩展点CBF构件接口调用接口定义和实现的分离支持构件功能的特定行为、算法和实现插件支持特定算法和行为的动态加载和执行构件的参数化支持构件对事件和状态变化的响应扩展点扩展点CBF插座插件模板抽象构件外观扩展点扩展点CBF构件组装参数化组装：运行参数、配置文件、脚本程序消息机制：消息中间件代理：桩方式、适配器、容器、WebService机制扩展点扩展点CBF脚本消息机制Web Services容器小结小结OOF和和CBF的不同的不同面向对象框架机制：面向对象技术的多态和继承机制复用方式：通过继承框架中的抽象类来完成特定行为的定制，白盒复用问题：框架的过度增值、脆弱的基类和隐式体系结构基于构件的框架机制：构件接口调用、构件组装等复用方式：通过一些集成机制得到对象或者构件的不同组装，来定义特定行为的，黑盒复用框架描述语言（框架描述语言（1/6）框架文档必须包含的内容框架的目的明确框架针对的问题域，以及框架为问题域的哪些问题提供了解决方案如何使用框架框架得到正确使用并发挥最优效果的关键所在应用实例阅读实例是理解框架主要结构的方法框架使用者可以从一组实例中看出框架的边界和不足框架的设计描述表达框架的整体体系结构和扩展点的设计细节框架描述语言（框架描述语言（2/6）CookBook途径类似“菜谱”的、一步一步讲述如何使用框架使用自然语言，举例说明框架的使用，易于理解对框架设计的描述不充分MVCCookBook方法、MacAppCookBook方法、ActiveCookBook方法框架描述语言（框架描述语言（3/6）模式途径主题（Motif）方法每一个主题描述一个待解决的问题，给出不同的解决方案适合描述框架如何被使用面向对象设计模式方法面向对象设计模式描述了部分的面向对象设计，并不适合表达一个面向对象框架的完整设计框架描述语言（框架描述语言（4/6）结构化语言途径框架描述语言（FDL）类似于C+函数说明形式化的框架实现语言以及实现模板没有给出框架的设计描述基于XML语言比较全面地给出了框架中的关键实体、实体的性质以及实体之间的关系对框架如何使用的描述不充分框架描述语言（框架描述语言（5/6）UML扩展途径UML-F采用一系列布尔类型的标识值来描述面向对象框架中的三种变化点：可变方法、可扩展类和可扩展接口variable标记值表示可变方法extensible标记值表示可扩展类dynamic和static标记值分别表示运行时配置或者非运行时配置的需求appl-class标记值表明一个类是否特定于应用incomplete用来表示可扩展接口框架描述语言（框架描述语言（6/6）框架描述途径比较CookBook模式途径主题 OO模式框架描述语言XML语言途径ULMF框架的目的好好差差差差如何使用框架好好好一般一般好应用范例好好差好好差设计细节的表达差好好差一般好框架总体结构的表达差一般好差一般一般框架的测试（框架的测试（1）框架测试的主要目的是验证开发完成的框架是否满足领域分析阶段的需求测试活动：单元测试：针对固定点集成测试：框架是否覆盖了所针对的领域构件之间的协作是否正确框架扩展点实现是否正确除了框架本身的测试，框架文档也是其中重要测试内容，需要验证框架文档是否正确的描述了框架扩展点框架的测试（框架的测试（2）由于框架是针对复用开发的软件制品，它并不是完整的应用系统，因此在进行测试时，需要采取以下策略：通过开发驱动模块调用框架接口，测试框架对外提供的功能在进行集成测试时，最有效的措施就是在领域中选择一个有代表性的应用系统进行构造，测试基于框架能否完成目标系统，即框架的可复用性。从这个角度来看，框架的复用过程也是框架的测试过程，一个被复用多次的框架，其正确性将有显著提高框架的维护（框架的维护（1）框架维护首要的目标是通过改善框架结构，提高框架性能以及可复用性，即完善性维护，原因：框架作为一种可复用资产，内部错误比例将随着不断复用大大降低框架是针对特定领域的，其设计已经考虑了变化性，具有较高的灵活性，可以通过框架扩展以实现需求的变化框架的维护（框架的维护（2）一系列重构（Refactoring）活动有助于实现框架的完善性维护，所谓重构，是指在不改变可观察行为的前提下，对软件内部结构的改变，目的是使它更易于理解并且能够更廉价地进行改变针对面向对象的软件框架，Opd92OJ93中总结了三类高层的重构方式抽象类重构：为具有一部分相同属性的类C1和C2创建一个抽象基类子类重构：将一个复杂的类分解成几个小一点的具体类和一个表达抽象的基类聚合类重构：识别聚积和部件框架的演化（框架的演化（1/2）应用框架的演化过程模型框架的演化（框架的演化（2/2）框架演化过程中需要考虑的问题：识别具有演化趋势的模块识别框架各版本之间改动较多的模块，这些模块应该是下一个版本中最可能被重构的模块确定框架发布的适当时间避免由于已发布的产品不符合功能和质量需求而造成的不必要的维护费用变化影响分析框架的演化对下一个版本的影响和基于前一个版本开发的应用的影响，变化影响分析结果可用来预测框架演化带来的维护工作量需求管理预测增加新的需求的成本，决定是否在框架实例或新版本框架中加入新需求框架构造原则框架构造原则单一责任原则开放-封闭原则Liskov替换原则依赖倒置原则接口隔离原则单一职责原则（单一职责原则（SRP）内容就一个类而言，应该仅有一个引起它变化的原因，这条原则被称为内聚性原则。一般地，内聚性是指一个模块组成元素之间的功能相关性。在本条原则中，把内聚性和引起一个模块或类的改变的作用联系起来。为了理解这一原则，首先要回答什么是职责？在SRP中，把职责定义为：引起变化的理由areasonofchange）。根据这一定义，显然可知：如果能够想到多个（1）动机来改变一个类，那么这个类就具有多于一个的职责。实践中，人们很习惯以“组”的形式来考虑类的职责。例如：一个接口“调制解调器”有四个功能：interfacemodempublicvoiddial(stringpno);publicvoidhangup();publicvoidsend(charc);publicvoidrecv();这显然违背了SRP原则！原因是，根据职责的定义，可以认为该接口有两个职责：连接处理publicvoiddial(stringpno);publicvoidhangup();数据通信publicvoidsend(charc);publicvoidrecv();是否将这2个职责分离取决于应用程序变化的方式：如果应用程序的变化会影响连接函数的声明（signature）,那么调用send和recv就必须重新编译，因此应分离这两种职责。如果应用程序的变化总是导致这两个职责同时变化，那么就不必分离这两种职责。耦合职责的分离就上一个例子而言，可以把2个职责分离为：interfaceinterfaceData ChannalData Channal+send(:char)+recv+send(:char)+recv():char():charinterfaceinterfaceC Connectiononnection+dial(pno:Stri+dial(pno:String)+hangup()ng)+hangup()Modem Modem ImplementationImplementation其中，可以把ModemImpiementation类看作是一个杂凑物（kludge），通过分离它们的接口，解耦了概念。所有的依赖关系都与ModemImpiementation类无关。除了main外，谁也不知道它的存在。持久化问题-左图给出了一种常见的违反该原则的情况其中，类Employee包含了业务规则和持久性控制。这2个职责在多数情况下不应该合在一起。因为业务规则往往会不断的变化，并且变化的原因也各不相同。处理：1）测试驱动的开发实践，往往会避免这种情况发生，即迫使对这2种职责进行分离。2）如果出现了这种情况，可以使用FAADE和PROXY模式对设计进行重构，分离这2种职责。Employee Employee+CalculatePay+CalculatePay+Store+StorePersistence Persistence SubsystemSubsystem结论SRP是最简单的一个原则，但也是最难运用的原则之一；在设计中，人们会自然地把职责合在一起；软件设计真正要做的许多内容，就是发现职责，并把这些职责相互分离。本质上，其它原则都是以这种或那种方式回答第3个结论：即分离职责。开放开放-封闭原则封闭原则(The Open-Closed Principle,OCP)两截门（DutchDoor）-一个被水平分割为两部分的门，这样的每一部分都可以独立保持开放或关闭。-美国英语传统字典，第4版，2000年内容：软件实体（类、模块、函数等）应该是可扩展的，但是不可修改的。这一原则是BertrandMeyer在1998年提出的。提出这一原则的背景之一：IvarJacobson曾经说过：“任何系统在其生存周期中都会发生变化。如果期望开发的系统不会在第1版本后就被抛弃，必须牢牢记住这一点。”遵循这一原则开发的软件具有以下特点：“对于扩展是开放的”（openforextention）这意味着模块的行为是可以扩展的。换言之，可以改变模块的功能。“对于改变是封闭的”（closedformodification）这意味着对模块行为改变时，不必改动模块的源代码或二进制代码。模块的二进制可执行版本，无论是可链接的库、DLL或Java的.jar文件，都无需改动。怎样才能做到看起来似乎矛盾的以上两点？关键的是抽象！不允许修改的模块，通常被认为是具有“固定”行为的模块。抽象基类以及可能的派生类，就能够描述一组任意可能行为的抽象体。模块可以操作一个抽象体。由于模块依赖一个“固定”的抽象体，因此它对于更改可以是封闭的；但通过该抽象体的派生，可以扩展该模块的行为。例如，ClientServerClientClient类是既不开放又不封闭的类类是既不开放又不封闭的类 （其中，其中，Client Client 类和类和ServerServer类类都是具体类）都是具体类）实现实现OCP的一种结构：的一种结构：Clientinterfaceinterface Client Client InterfaceInterfaceServerSTRATEGYSTRATEGY模式：既开放又封闭的模式：既开放又封闭的Client Client 其中，其中，ClientInterfaceClientInterface类是一个拥有抽象成员的抽象类。类是一个拥有抽象成员的抽象类。Client Client 类使类使用这个抽象类，但用这个抽象类，但Client Client 类的对象却使用类的对象却使用ServerServer类的派生类的对象。类的派生类的对象。因此，如果希望因此，如果希望Client Client 对象使用一个不同的服务器类，那么只需从对象使用一个不同的服务器类，那么只需从ClientInterfaceClientInterface类派生一个新的类，而无需对类派生一个新的类，而无需对Client Client 类进行任何改动。类进行任何改动。Client Client 类需要实现一些功能，可以使用类需要实现一些功能，可以使用ClientInterfaceClientInterface的抽象接口来的抽象接口来描述这些功能。描述这些功能。ClientInterfaceClientInterface的子类型可以以任何方式来实现这个的子类型可以以任何方式来实现这个接口。这样，就可以通过创建接口。这样，就可以通过创建ClientInterfaceClientInterface的新的子类型的方式来扩的新的子类型的方式来扩展、更改展、更改Client Client 中指定的行为。中指定的行为。实现实现OCP的另一结构：的另一结构：PolicyPolicy+PolicyFunction()+PolicyFunction()-ServiceFunction()-ServiceFunction()Implementation-ServiceFunction()-ServiceFunction()Template MethodTemplate Method模式：既开放又封闭的基类模式：既开放又封闭的基类 其中，其中，PolicyPolicy类具有一组实现了某种策略的共有函数。和上图中的类具有一组实现了某种策略的共有函数。和上图中的ClientClient类中的函数类似，这些策略函数使用一些抽象接口描述了一些要完成的功类中的函数类似，这些策略函数使用一些抽象接口描述了一些要完成的功能。不同的是，在这个结构中，这些抽象接口是能。不同的是，在这个结构中，这些抽象接口是PolicyPolicy 类的一部分。它们类的一部分。它们在在C+C+中表现为纯虚函数，在中表现为纯虚函数，在JavaJava中表现为抽象方法。这些函数在中表现为抽象方法。这些函数在PolicyPolicy的的子类型中实现。这样，可以通过从子类型中实现。这样，可以通过从PolicyPolicy类派生出新类的方式，对类派生出新类的方式，对PolicyPolicy中指定的行为进行扩展或更改。中指定的行为进行扩展或更改。以上两个模式是满足以上两个模式是满足OCPOCP原则最常用的方法。应用它们，可以把一个功原则最常用的方法。应用它们，可以把一个功能的通用部分和实现细节清晰地分离开来。能的通用部分和实现细节清晰地分离开来。结论在许多方面，开发-封闭原则（OCP）都是面向对象设计的核心。遵循这一原则，可以带来巨大好处-灵活性、可复用性以及可维护性。不是使用了面向对象语言就是遵循了这一原则。对应用程序中的每一部分肆意地使用抽象，同样不是一个好的主意。正确的做法是，开发人员应该仅对呈现频繁变化的那些部分做出抽象。其中，“拒绝不成熟的抽象与抽象本身一样重要的”。Liskov替换原则替换原则(LSP)在C+和Java这类语言中，支持抽象和多态的关键机制是继承（inheritance）。正是使用了继承，才可能创建实现其基类中抽象方法中的派生类。是什么设计原则支配这种特殊的继承用法？最佳的继承层次的特征是什么？怎样的情况会使创建的类层次陷入不符合OCP？以上正是LSP原则要回答的问题。内容：子类型必须能够替换掉它们的基类型。这一原则是BarbaraLiskov在1988年首先提出的。“若对每个类型S的对象o1,都存在一个类型T的对象o2,使得在所有针对编写的程序P中，用o1,替换o2后，程序P行为功能不变，则S是T的子类型。”若违反这一原则，会出现什么后果？例如：假定有一个函数f，它的参数指向某个基类B的“指针”或“引用”。同样，假定有B的某个派生类D，如果把D的对象作为B类型传递给f，就会导致f出现错误的行为。那么D就违反了LSP。显然，D对于f来说是脆弱的。违反LSP，常常以违反OCP的方式使用运行时的类型辨别（RTTI）而导致的。这种方式往往是显式地使用一个if语句或if/else来确定一个对象的类型，以便可以选择该类型的正确行为。考虑以下程序：structPointdoublex,y;structShapeenumShapeTypesquare,circleitsType;Shape(ShapeTypet):itsType;structCircle:publicShapeCircle():Shape(Circle);voidDraw()const;PointitsCenter;doubleitsRadius;structSquare:publicShapeSqaure():Shape(Sqaure);voidDraw()const;PointitsTopLeft;doubleitsSide;voidDrawShape(constShape&s)if(s.itsType=Shape:square)static_cast(s).Draw();elseif(s.itsType=Shape:circle)static_cast(s).Draw();显然，该程序中的DrawShape函数违反了OCP它必须知道Shape类所有的派生类，且每次创建一个Shape的派生类都必须要更改它。其原因是，Square类和Circle类是Shape的派生类，具有函数Draw（），但没有重写（override）Shape中的函数。由于Square类和Circle类不能替换Shape，所以DrawShape函数必须检查输入的Shape对象，确定它的类型，继之调用函数Draw（）。Square类和Circle类不能替换Shape，这违反了LSP，从而使DrawShape违反了OCP。还有其它一些方式，可以引发违反Liskov替换原则。例如：isA关系的使用-没有把子类中那些不具有多态性的函数声明为虚函数；基于契约设计的使用-派生类违反了有关基类的约定。在派生类的方法中填加了其基类不能割舍的异常结论：LSP是使OCP成为可能的主要原因之一。正是子类型的可替换性，才使使用基类的模块在无须改变的情况下可以予以扩展。这种可替换性必须是开发人员可以隐式依赖的东西。因此如果没有显示地强制基类类型的契约，那么代码就必须良好地并显式地表达出这一点。“is-A”的含义过于宽泛，以至于不能作为子类型的定义。子类型的正确定义是“可替换性的”，这里的可替换性可以通过显式或隐式的契约予以定义。依赖倒置原则依赖倒置原则(DIP)内容：高层模块不应该依赖低层模块。二者都应该依赖抽象。抽象不应该依赖细节。细节应该依赖抽象。该原则是框架设计的核心原则层次化Booch曾经说过：“所有结构良好的面向对象构架都具有清晰的层次定义，每个层次通过一个定义良好的、受控的接口向外提供一组内聚的服务。”对以上这句话的简单理解，可能会出现以下结构：Policy LayerMechanism LayerUtility Layer这一结构存在一个潜伏的错误特征这一结构存在一个潜伏的错误特征：（1 1）Policy layerPolicy layer对于其下一直到对于其下一直到 Utility LayerUtility Layer的改动，都的改动，都 是敏感的。是敏感的。（2 2）这种依赖是可传递的。）这种依赖是可传递的。-结论：这一结构是不好的！结论：这一结构是不好的！合适的模型应该是：PolicyPolicyMechanism Mechanism UtilityUtilityPolicPolicy y LayerLayerinterfaceinterfacePolicy Policy Service Service InterfaceInterfaceMechanism Mechanism LayerLayerinterfaceinterface Mechanism Service Mechanism Service InterfaceInterfaceUtiliUtility ty LayerLayer 每个较高层次为它所每个较高层次为它所需要的服务声明一个抽需要的服务声明一个抽象接口，较低层次实现象接口，较低层次实现这些抽象接口；这些抽象接口；每个较高层次都通过每个较高层次都通过抽象接口使用下一层。抽象接口使用下一层。这样这样1 1）高层就不依赖低层，）高层就不依赖低层，而低层则依赖高层；而低层则依赖高层；2 2）不仅解除了其中的）不仅解除了其中的传递依赖关系，而且还传递依赖关系，而且还解除了高层与其它层的解除了高层与其它层的依赖关系。依赖关系。倒置的接口所有权问题这就是著名的Hollywood原则“Dontcallus,wellcallyou.”即低层模块实现了在高层模块中声明并被高层模块调用的接口。依赖于抽象这是解释DIP规则的一个启发式规则。该规则建议不应该依赖具体类-即程序中的所有依赖关系都应该终止于抽象类或接口。根据这个启发式规则，可知：任何变量都不应该持有一个指向具体类的指针或引用；任何类都不应该从具体类派生；任何方法都不应该覆写它的任何基类中已实现的方法。注意：在编程中，有时必须要创建具体类的实例，而创建这些实例的模块将会依赖它们。这说明程序中一般都会出现违反启发式规则的情况。如果一个具体类不太会改变，且不会创建其它类似的派生类，那么依赖它也不会造成损害。这说明对那些稳定的具体类而言，启发式规则似乎不大合理。如果具体类是不稳定的，且还不想直接依赖之，则可以把它们隐藏在抽象接口之后，以隔离它们的不稳定性。依赖倒置规则可应用于任何存在一个类向另一个类发送消息的地方。违反依赖倒置原则的例子：ButtonButton+poll()poll()LampLamp+turnOn()+turnOffturnOn()+turnOff()()这是一个以这是一个以ButtonButton控制控制LampLamp的系统。的系统。其中，其中，ButtonButton类直接依类直接依赖赖LampLamp对象，这个设计对象，这个设计不能让不能让ButtonButton控制其它控制其它设备。设备。该设计方案就违反了该设计方案就违反了DIPDIP，即应用程序的高即应用程序的高层策略没有与低层策略层策略没有与低层策略相分离，自然使抽象依相分离，自然使抽象依赖于具体细节。赖于具体细节。其对应的其对应的JavaJava如左所示。如左所示。什么是高层策略？它是应用的抽象，是那些不随具体细节而改变的“真理”。它是系统内部的系统-隐喻(metaphore)ButtonButton+poll(poll()interfaceinterfaceB ButtonServeruttonServer+turnOn()turnOn()+turnOff()+turnOff()Lamp Lamp通过倒置对通过倒置对LampLamp的依赖关系，可以形成以上的设计。的依赖关系，可以形成以上的设计。其中，由接口其中，由接口ButtonServerButtonServer提供一些抽象方法，提供一些抽象方法，ButtonButton可以使用这些可以使用这些方法对有关设备进行方法对有关设备进行控制。由控制。由LampLamp来实现接口来实现接口ButtonServerButtonServer。这样的设计就具有很好的灵活性。但问题是这样的设计就具有很好的灵活性。但问题是LampLamp可能还受其他类的控可能还受其他类的控制。但由于制。但由于LampLamp实现了接口实现了接口ButtonServerButtonServer，所以就做不到这一点。所以就做不到这一点。结论：使用传统的过程化设计所创建的依赖关系结构，策略是依赖于细节的。这样会使策略受到细节改变的影响。面向对象程序设计倒置了依赖关系的结构，是策略和细节都依赖抽象，并且通常是客户的服务接口。这种依赖关系的倒置，正好是面向对象的标志所在。依赖倒置原则是实现许多面向对象技术所宣称的那些益处的低层机制。它的正确应用对创建可复用的框架是必须的。同时对建造具有弹性的代码（应对变化）是非常重要的。应用该原则可以做到抽象和细节彼此分离，因此代码也易于维护。接口隔离原则接口隔离原则(ISP)内容：不应强迫客户（client）依赖它们不用的方法。解决的问题：ISP原则用来处理“胖接口”所带来的缺点。何谓胖接口？如果类的接口不是内聚的，则称该接口是胖接口。换言之，类的胖接口可以分解为多组方法，每一组方法服务于一组不同客户程序。接口污染问题考虑一个安全系统。其中有一些Door对象，可以加锁和解锁，并且知道自己所处的状态（开/关）。classDoorpublic:virtualvoidLock()=0;virtualvoidUnLock()=0;virtualboolIsDoorOpen()=0;显然，这是一个抽象类。客户程序可以使用符合Door的那些接口对象，而不依赖Door的特定实现。现在考虑这样一个实现-TimedDoor.其中，如果门开着的时间过长，就会发出警报。为此，TimedDoor对象需要和一个名为Timer的对象进行交互。即如果希望得到超时时间，就可以调用Timer的Register函数,该函数有2个参数：一个是超时时间，另一个是TimerClient对象的指针，该对象的TimeOut函数会在达到超时时予以调用。现在的问题是，如何建立类TimerClient和类TimedDoor之间的关联，才能在超时时通知TimedDoor中相应的处理代码？下面给出了一种可想到的方案：TimerDoorTimedDoorInterface Timer Client+Timeout0.*其中，其中，DoorDoor继承了继承了Timer ClientTimer Client，因此因此TimedDoorTimedDoor也继承了也继承了Timer ClientTimer Client，这就可以保证这就可以保证TimerClientTimerClient把自己注把自己注册到册到TimerTimer中，并可接收中，并可接收TimeOutTimeOut的消的消息。息。现在的问题是，如何建立类现在的问题是，如何建立类TimerClientTimerClient和类和类TimedDoorTimedDoor之间之间的关联，才能在超时时通知的关联，才能在超时时通知TimedDoorTimedDoor中相应的处理代码？中相应的处理代码？下面给出了一种可想到的方案：下面给出了一种可想到的方案：TimerInterface Timer Client+TimeoutDoorTimedDoor0.*其中，其中，DoorDoor继承了继承了Timer ClientTimer Client，因此因此TimedDoorTimedDoor也继承了也继承了Timer ClientTimer Client，这就可以保证这就可以保证TimerClientTimerClient把自己注把自己注册到册到TimerTimer中，并可接收中，并可接收TimeOutTimeOut的消的消息。息。现在现在,类类DoorDoor依赖于依赖于TimerClientTimerClient。该方案的主要问题就出现该方案的主要问题就出现在这里。在这里。1 1）不是所有种类的）不是所有种类的DoorDoor都需要定时功能。最初的都需要定时功能。最初的DoorDoor与定与定时功能没有任何关系，如果需要创建一个没有定时功能的派生时功能没有任何关系，如果需要创建一个没有定时功能的派生类，那么就必须要提供类，那么就必须要提供TimeOutTimeOut方法方法的的“退化退化”实现，这就违反实现，这就违反了接口分离原则。了接口
