uml与设计模式.pdf

《uml与设计模式.pdf》由会员分享，可在线阅读，更多相关《uml与设计模式.pdf（37页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、返回总目录返回总目录返回总目录返回总目录目目目目 录录录录第第第第 10 章章章章 UML 与设计模式与设计模式与设计模式与设计模式.210.1 什么是模式.210.2 为什么要使用设计模式.310.3 模式的分类.410.4 模式的组成元素.610.5 模式的质量.710.6 一个简单的模式例子代理模式.810.7 UML 对模式的支持.910.8 应用设计模式进行系统设计.1410.9 模式选择举例评估项目.1510.10 模式应用举例形状编辑器.2010.11 小 结.36第 10 章 UML 与设计模式过去几年在面向对象领域中的一个重要突破就是提出了设计模式的概念设计模式由于实用而受到

2、欢迎它们能够表达和重用专家技术和经验能进行系统框架设计在表达上既经济又清楚从而受到人们越来越多的重视模式概念是建筑师 Christopher Alexander 提出的他提出可以把现实中一些已经实现的较好的建筑和房屋的设计经验作为模式在以后的设计中直接加以运用他还定义了一种模式语言来描述建筑和城市中成功的架构Alexander 的方法得到软件业人士的青睐在 20 世纪 90 年代掀起了一股在软件设计中应用模式的讨论1994 年 8 月召开了编程模式语言Pattern Languages of ProgramsPLoP大会尽管软件的设计模式不一定要和面向对象有关但由于面向对象很容易描述设计抽象因

3、而许多设计模式都和面向开发有关Erich GammaRichard HelmRalph Johnson 和 John Vlissides 四个人被称为四人组在 1995 年初出版了一本书Design Patterns:Elements of Reusable Object-OrientedSoftware(设计模式可重用的面向对象软件的元素)其中对设计模式进行了基本分类并且讨论了一些新的需要研究的模式不过软件界的设计模式仍然处于起步阶段远不如它在建筑业中那么成熟和完善对模式的研究有许多方面例如有的讨论如何在不同的领域内如 CORBA 和项目管理中应用模式有的则讨论模式系统希望能够识别出不同级别

4、的模式最终形成一个完整的模式系统还有的则研究组织系统的架构模式子系统责任和规则分配以及有关子系统如何通信和合作的准则而 UML 的设计师们也正在研究如何用设计模式支持软件开发过程同时 UML 本身就支持模式的表达在本章我们首先介绍模式的一些基本概念如模式的定义分类和它的优点接着将介绍 UML 对设计模式的支持最后将通过几个具体的例子来讨论如何使用设计模式进行系统设计10.1 什么是模式那么什么是模式Pattern呢Alexander 给出的定义最为经典每个模式都描述了一个在我们的环境中不断出现的问题然后描述了该问题的解决方案的核心通过这种方式你可以无数次地使用那些已有的解决方案无需再重复相同的

5、工作模式作为现实世界中的一个元素都是以下这三者之间的关系它们是特定的情景在该情景下反复出现的特定压力系统和使这些压力能够自我释放的空间配置作为语言的一个元素模式是一条指令说明了如何重复地使用这个空间配置一旦给定的情景适当就释放给定的压力系统简而言之模式是一种出现在现实世界的事物同时它也是一条告诉我们如何创建何时创建该事物的规则它既是一个过程又是一种事物既是对一个存在事物的描述又是对生成该事物过程的描述模式具有双重性它既是生成的generative又是描述的descriptive因为它既是对重复生成的架构元素的描述又是对如何以及何时创建该元素的规则从本体论ontological的观点来说模式的生

6、成的属性指模式的内容content即指反复出现的事物的自身从认识论epistemological的观点来说描述的属性指模式的形式form是我们捕捉并表述这一事物的方式通过问题情况压力解决的形式简而言之设计模式的核心是问题描述和解决方案问题描述说明模式的最佳使用场合以及它将如何解决问题解决方案是用一组类和对象及其结构和动态协作来描述的10.2 为什么要使用设计模式在软件业中设计模式是面向对象系统使用的一些可重用的已经得到了很好证明的巧妙通用简单的设计解决方案软件设计中的设计模式具有以下特性?巧妙设计模式是一些优雅的解决方案一般很难立刻设计出来?通用设计模式通常不依赖某个特定的系统类型程序设计语言

7、或应用领域它们是通用的?得到了很好的证明设计模式在实际系统和面向对象系统中得到广泛应用它们并不仅仅停留在理论上?简单设计模式通常都非常小只涉及很少一些类为了构建更多更复杂的解决方案可以把不同的设计模式与应用代码结合或混合起来使用?可重用设计模式的建档方式使它们非常易于使用正如前面提到的它们非常通用因而可用于任何类型的系统注意此处的可重用性是在设计层而不是在代码层设计模式平在类库中只有系统架构使用它们?面向对象设计模式是用最基本的面向对象机制如类对象通用化和多态等构造的那么为什么要使用模式呢首先使用设计模式就可以更准确地描述问题和它们的解决方案其次使用设计模式可以具有一致性consistency

8、即如果对一些已知的问题我们有一类标准的解决方案那么在遇到相同问题时我们能够采取一致的方法这就使代码更容易理解使用设计模式的再一个原因就是在遇到问题时无需每次都从底层做起而是可以从标准解决方案设计模式入手并对它改编使之适应特殊问题的需要这样就节省了时间并且提高了开发的质量模式为面向对象软件开发人员提供了以下机制?根据实际系统的开发经验提供对共同问题的可重用的解决方案?提供类和对象级之上抽象的名称通过设计模式开发人员能够在更高的层次上讨论方案 例如我建议我们可以用 Bridge 或 Adapter 来解决这个问题 Bridge和 Adapter 是两种设计模式?提供对开发的功能性和非功能性方面的处

9、理方案许多模式特别强调了某些面向对象设计擅长的领域区分接口和实现放松各部分之间的依赖性隔离硬件和软件平台并且具有重用设计和代码的潜能?提供了开发框架framework和工具的基础在设计可重用框架时设计模式是最基本的架构?为面向编程和设计学习提供教育和训练支持通过对设计模式的研究能够深入理解良好设计的最基本性质从而在后面的设计中加以模拟和应用10.3 模式的分类不同的书籍和论文在描述设计模式时的方式各有差异有的采用文本方式有的采用文本和建模语言模型的方式也有多种对模式的分类方法四人组书中定义了 23 种模式的分类该书的文档风格现在成为定义新模式的模板该书定义了以下几种模式分类?创建模式针对例程包

10、括创建什么对象以及如何及何时创建和类及对象的配置 允许系统中有不同结构和功能的 产品 对象 常见的创建模式有 AbstractFactoryFactory MethodPrototypeSingletonObject Pool图 10-1 是一个 Builder的例子:MessageManager1:receive(msg:MIMEMsg):MIMEParser1.1:outMsg:=parse(msg:MIMEMsg)MessageBuilder1.1.1:builder:=getInstance(to:String)builder:MAPIBuilder1.1.2:to(:String)1

11、.1.3:from(:String)1.1.4:plainText(:String)1.1.5:jpegImage(:Image)1.1.6:outMsg:=getOutboundMsg()outMsg:OutboundMessageIF new1.2:send()图 10-1 Builder 模式举例?结构模式针对在大的结构中使用类和对象的方式并把接口与实现分离开来ObjectKeyCacheManagerfetchObject(:ObjectKey)ObjectCreatercreatObject(:ObjectKey)Create-objects-for-caching11Cachead

12、dObject(:Object)fetchObject(:ObjectKey)?Cache-objects-for11Object10.*Caches?fetchercacher图 10-2 Cache Management 模式?行为模式针对在对象之间责任分配的算法以及类和对象之间的动态交互行为模式不仅仅处理对象的结构还处理它们之间的通信 Chain of ResponsibilityCommandLittle Language/InterpreterMediatorSnapshotObserverStateNullObjectStrategy TemplateMethodVisitor图

13、10-3 是 Visitor 模式ClientVisitor#navigationOperation1():AbstactElement#navigationOperation2():AbstractElement.ConcreteVisitor1ConcreteVisitor2.ObjectStructureAbstractElementConcreteElement1ConcreteElement2.Uses?Contains?10.*?UsesUses?Uses?111navagates?1110.*图 10-3 Visitor 模式10.4 模式的组成元素Alexander 说我们定义

14、的每个模式都应该以规则的形式在情景情景下产生的压力系统以及允许这种压力自我释放的配置之间建立关系他还推荐使用图来描述模式Alexander 所使用的模式的描述格式称为Alexandrian 方式在GoF中使用的称为GoF格式不管模式的记录方式有多大的区别它都应该包括一些本质的元素以下是一些公认的模式基本元素?名模式必须具有一个有意义的名这样就可以用一个词或短语来指代该模式以及它所描述的知识和结构好的模式名组成讨论概念抽象的词汇表有时一种模式可能有多个公认的名字这种情况下最好把它的绰号以及同义词在别名或也作为中列出有的模式格式还提供模式的分类?问题陈述问题并描述它的意图它在给定的情景和压力下所要

15、达到的目标和目的通常压力是阻碍完成这些目的的?情景是问题以及它的解决方法重复发生的前置条件告诉我们模式的可应用性applicability也可以把它看作应用模式前的系统初始配置?压力描述有关的压力和约束它们之间以及和要达到的目标之间是如何交互/冲突的常常使用一个具体的想法作为模式的动机motivation压力揭示了问题的错综复杂同时定义了在它们产生冲突时必须做的折衷好的模式描述应该完全封装所有对它有影响的压力?解决方案描述如何实现预期结果的静态关系和动态规则相当于给出指令来构造所需要的产品描述中可以有画图和句子它们指明模式的结构参与人和他们之间的协作进而说明问题是如何解决的解决方案不仅要描述静

16、态结构还要描述动态行为静态结构说明了模式的形式和组织而行为动态则使模式变得生动对模式解决方案的描述可能指明了在尝试构造该方案的具体实现时应该记住的指南有时也会描述该解决方案的一些变形或专有化?例子一个或多个应用模式的例子显示特定的初始情景如何应用模式模式如何改变情景以及结果的情景例子帮助读者理解模式的使用和可应用性虚拟的例子和模拟尤其具有说服力例子还可以附加一个实现例子显示解决方案实现的一种方式?结果情景在应用模式之后系统的状态或配置包括应用模式所产生的结果包括好的和坏的以及模式可能带来的其它问题它描述了模式的后置条件和边际效应这有时称作压力的释放因为它描述了哪个压力已经被释放哪个还没有释放现

17、在哪个模式是可应用的为模式产生的最后情景编制文档有助于把其它模式的初始情景关联起来因为在大型项目中一个模式通常只是完成整个任务的一小步?基本原理对模式中的步骤和规则的证明性解释告诉我们模式实际上的工作方式以及为什么要采取这样的方式为什么这样是最好的模式的解决方案组件可能描述模式的外部可见的结构和行为而基本原理组件则说明了模式内在的结构和主要的机制?相关模式在同一模式语言或系统中该模式与其它模式之间的静态和动态关系相关模式通常会有相同的压力并且会有与其它模式相容的初始或结果情景这样的模式可能是前任模式其应用导致该模式的应用也可能是后继模式其应用紧跟在该模式应用之后可能是其它可选模式针对与该模式相

18、同的问题在不同的压力和约束下提出不同的解决方案还可能是互相关的模式与该模式同时应用?已知使用描述该模式在已有系统中的出现和应用这有助于确认该模式的确是针对一个重复出现的问题的一个得到证明的解决模式的已知使用经常用作模式的使用指导虽然没有提出严格的要求但通常好的模式前面都有一个摘要提供一个简短的总结和概述为模式描绘出一个清晰的图画提供有关该模式能够解决问题的快速信息有时这种描述称为模式的缩略概要或一个模式缩略图模式应该说明它的目标读者以及对读者有哪些知识要求10.5 模式的质量除了包含上述的元素外定义良好的模式还应该具有一些重要的质量包括?封装和抽象每个模式都封装了在特定领域内一个定义良好的问题

19、以及它的解决方案模式应该有清晰的边界概念以便于明确问题空间和解决方案空间模式还应该是抽象体现了领域知识和经验并且可能出现在该领域内不同的概念层次上?开放性和可变性每个模式都应该是开放的允许对它进行扩展或被其它模式参数化来共同解决大问题模式的解决方案也应该能够有无限种实现的方式孤立地或与其它任何模式一起?可再生性和可共存性一旦被应用那么每个模式都会生成一个结果情景这个情景可能会与一个或多个其它模式的初始情景匹配而后会继续应用后面的模式直到最终生成一个完整的解决方案但模式的应用通常不是线性的很可能一个模式的一部分会在特定的抽象和精细层次上导致其它不同层次上的模式或与它们复合?平衡每个模式必须实现它

20、的压力和约束之间的某种平衡这种平衡可能来自用来使解决方案空间冲突最小化的一个或多个不变量和启发式这种不变量通常代表了解决问题最基本的原则或思想并解释了该模式中的每一个步骤或规则总之模式的目标是通过把它的每一组成部分技巧性地组织起来使它的整体和大于部分和10.6 一个简单的模式例子代理模式了解设计模式的最好办法就是去研究一个实际的模式下面我们就以代理模式为例进行讨论代理模式是一个结构模式把接口从实现中分离成不同的类它的主要思想是用一个代理对象作为另一个真实对象的代理由这个代理控制所有对真实对象的接入从而解决了当由于性质位置或接入限制而使得真实对象无法被直接实例化的问题这是一个非常简单的模式但很容

21、易说明 UML 是如何描述模式的图 10-4 是 UML 中 Proxy 模式的类图ClientSubjectRequest().Request();.ProxyRequest()RealSubjectRequest()图 10-4 把 Proxy 设计模式描述成一个 UML 类图注意Subject 是一个抽象类因而是斜体Proxy 模式涉及三个类SubjectRealSubject 和 Proxy图中的 Client 类使用该模式使用抽象类 Subject 中定义的接口在 RealSubject 和 Proxy 中都实现了 Subject 定义的接口RealSubject 实现了接口中的操作

22、而 Proxy 类则把它收到的所有调用都委托给RealSubject 去执行由 Proxy 对象控制对 RealSubject 对象的接入这一模式有以下几种应用场合?更高的性能和效率在需要真正的对象之间系统可以用廉价的代理来减少耗费当在代理处调用操作时它首先检查是否已经实例化 RealSubject 对象如果没有就把它实例化并把请求委托给它如果已经实例化了则立即转发请求这种方法在 RealSubject 对象的创建非常昂贵时很有效比如必须读取数据库复杂的初始化等许多具有很长的启动时间的系统通过使用 Proxy 模式可以显著地提高性能?授权 如果需要检查调用方是否具有调用 RealSubject

23、 对象的授权 则可以由 Proxy来完成这时调用方必须给出它自己的身份Proxy 必须和某个授权对象通信是否允许接入?局部化 RealSubject 对象可以位于其它系统中 本地的 Proxy 只是在本系统中 扮演它的角色而所有请求都被转发给其它系统本地客户只看到 ProxyProxy 模式可以有许多种变形如完成其它功能无需全部委托给 RealSubject可以改变参数的类型或操作的名词或者做一些准备工作来减少 RealSubject 的负荷这些变形体现了模式背后的思想模式是一种解决方案的核心可以有多种变形改装或扩展但不改变基本的方案在四人组的书中是用类图描述模式的用一个对象图和一个消息图有点

24、类似UML 中的序列图很多地方是用文本来描述某些方面如意图动机可应用性结构协作实现举例的代码以及模式的结合另外还包括同一模式其它的名字有类似性质的相关模式以及已知的该模式的用法模式的代码通常都简单根据需要把 RealSubject 实例化的 Proxy 类的 Java 代码很简单如图 10-5 所示public class Proxy extends ObjectRealSubject refersTo;public void Request()if(refersTo=null)refersTo=new RealSubject();refersTo.Request();图 10-5 把 Rea

25、lSubject 实例化的 Proxy 类的 Java 代码10.7 UML 对模式的支持在应用设计模式时UML 非常重要因为它允许模式作为架构的一部分如图 10-6所示图 10-6 在 UML 中模式的具体化图中 Oberserver 是设计模式同时还显示在该模式的特定使用中出现的实际的类在 UML 中模式是用一个协作描述的协作描述了情景和交互其中情景是指协作所涉及的所有对象它们之间的相互关系以及分别是哪个类的实例交互显示了在协作中对象完成的操作发送消息以及相互调用模式具有情景和交互因此很适合用协作来描述事实上是用一个参数化协作来描述的图 10-7 中的虚椭圆就是模式的符号里面是模式的名字模

26、式必须有名字图 10-8是 Proxy 模式对象图图中表明 Client 对象有一个链接是连到 Proxy 对象的然后又连接到 RealSubject 对象上 模式名图 10-7 一个协作符号代表一个设计模式aProxy:ProxyaClient:ClientaRealSubject:RealSubject图 10-8 用对象图描述 Proxy 模式的情景在描述 Proxy 模式时交互显示了当客户提出请求时对象是如何交互的图 10-9 中的序列图显示了如何把请求授权给 RealSubject 对象以及结果是如何返回给客户的协作图可以在同一个图中显示出情景和交互图 10-8 的对象图中的情景以及

27、图 10-9中的交互都体现在图 10-10 中的协作图中了是否使用协作图或者分别表示在一个对象图和一个序列图中依情况而定更复杂的模式可能需要描述几个交互来显示该模式不同的行为aClient:ClientaProxy:ProxyaRealSubject:RealSubjectRequest()Request()图 10-9 用序列图描述 Proxy 设计模式aClient:ClientaProxy:ProxyaRealSubject:RealSubject1:Request()4:2:Request()3:图 10-10 用协作图描述 Proxy 设计模式ProxyStaticsticsInte

28、rfaceSalesStaticsticsSalesrealsubjectsubjectproxy图 10-11 在一个类图中使用的 Proxy 模式其中 Statistics Interface 类有 subject 参与Sales 类有 proxy类参与Sale Statistics 类有 realsubject 参与10.7.1 参数化协作前面提到实际上是用参数化协作或一个模板模式描述模式的参数可以是在实例化模板时指定的类型如类关系或者操作在一个参数化协作中参数叫做参加人participant是类关系或操作设计模式参加人是模式定义的完成角色的应用元素例如在 Proxy 模式中的担任 Su

29、bjectProxy 和 RealSubject 类的类在图中参加人的表示是一个从模式符号与完成不同角色元素之间的一个相关性关联描述的该相关性上标注了参加角色的名说明了在设计模式中该类所扮演的角色在 Proxy 模式中参加的角色是 SubjectProxy 和 RealSubject如果要扩展协作则必须用参加的类显示出模式的情景和接口图 10-11 有意识地使参加人的类名与它们所扮演的角色不同以此表明它在模式中的任务是由相关中的角色名定义的 在实践中 通常都使类的名适合模式 例如 Sales 类叫做 SalesProxy SaleStatistics类叫做 SalesStatisticsSub

30、ject 类等等但是如果已经定义了该类或它们参加了几种模式就不能这样了如果要对协作进行扩展则显示出参加人在该模式中所扮演的角色如图 10-12 所示ClientSales InterfaceSum().Sum();.SalesSum()Sales StatisticsSum()图 10-12 用图 10-11 中的参加人扩展 Proxy 模式数据库连接FacadeObserver主体观察人子系统类外观子系统类子系统类引用图形窗口数据库语句数据库查询数据库系统股票查询服务器GetCurrentPrice()GetHistoricalPrices()图 10-13 模式是生成子这个类图显示了一组类

31、它们的部分情景和协作是用模式描述的10.7.2 对使用模式的建议模式被定义成参数化协作有自己的名字比基本元素的抽象级别高代表了设计层的构造在不同的设计中可以重复使用同一个模式因为使用模式后无需显示出系统的所有部分所以设计良好的模式可简化系统的描述模式中的情景和交互是隐含的因此可以把模式看作设计方案的通用化子如图 10-13 所示在开发过程中开发人员可以在图中扩展或隐藏模式所代表的情景和交互用参加模式的类表示UML 中用参数化协作来描述模式是很自然的以下是一些使用设计模式的建议?模式的名非常重要模式的名是比模式中的设计元素抽象级别符号设计模式的一个非常重要的性质就是能够在很高的抽象级别上进行通信

32、和讨论?确保项目中所有的人都了解模式有的模式非常简单很容易给开发人员造成错觉认为完全理解了模式的所有隐含意义但往往事与愿违所以在使用模式时一定要注重建档和训练?可以改装或修改模式但不要改变它们的基本性质在不改变模式的基本核心的前提下可以有很多方法来改装或修改模式因为模式的核心通常是使用它的最根本原因最好不要随便删除或改变?强调模式是一种可重用的设计许多机构都想把模式变换成可重用的代码类库和程序这样模式就只有一种特定的实现而其它的变形都无法使用了应该强调模式是在设计层面上的重用而不是在代码层面的重用?注意新模式会有许多新模式以及模式在新领域的应用不断涌现出来不断跟踪各种书籍杂志参加会议并游览互联

33、网将十分有利10.7.3 模式和用例之间的联系当我们更深入研究模式后会发现模式与用例的实现之间有着某种相似之处它们都有以下几种特性?情景两者都是用具有某种结构的一个对象的网络描述的?交互关于对象如何协作都有一个主要的交互它们在模式或用例中的行为?参加人它们都由一组应用类实例化这组类在模式或用例扮演特定的角色另外在 UML 中用例的实现方式和模式的建档方式是一样的参数化协作可以代表一个模式也可以代表对用例实现的描述协作的名是模式或用例的名协作与参加的类相关可以把模式看成一个通用的协作多个系统都能用它而用例是专用的通常只能由一个系统使用见图 10-14 所示销售保险Observer保险销售信息 客

34、户保险登记窗口报价图窗口股票报价服务器观察人主体图 10-14 用例协作和模式协作其中模式协作与参加的类相关10.8 应用设计模式进行系统设计模式自身是无法构成设计方法的它是在软件开发周期的某些阶段支持设计人员进行设计的基本构件它们可以使某些决策过程更为具体本节我们将举例说明如何在软件的开发周期中使用设计模式 这一节我们将讨论如何在系统设计中应用设计模式10.8.1 应用设计模式的主要活动设计模式与软件开发过程有什么样的关系呢我们可以把以下设计模式的主要活动应用在开发周期中如图 10-15 所示?模式实例化这是标准的模式实践选择一个设计模式生成设计的一部分?标识候选模式这是一个非标准的模式实践

35、在给定类结构中找到一个位置为了达到设计灵活性的目的插入一个设计模式实例分析分析分析分析演化演化演化演化设计设计设计设计实现实现实现实现模式实例化模式实例化模式实例化模式实例化模式候选标识模式候选标识模式候选标识模式候选标识图 10-15 与模式有关的活动10.8.2 实例化和标识模式的步骤前面我们区分了两种主要的模式活动1用模式进行设计2通过模式使设计更为灵活 第一种称为把模式实例化第二种称为在给定类结构中标识候选模式这两种活动都可以划分为四个前两个有关做决策的问题后两个有关结构变化注意这些步骤并不代表设计方法它们只是明确使用模式的认知和技术过程?步骤 1搜索和选择 设计人员寻求一种适合的设计

36、模式或者在给定的设计中标识出模式候选对模式实例化的工作是在设计的初始阶段进行的而标识候选模式则是在原型或工作系统开始工作以后例如当证明某个设计组件的功能还不够时通过在类结构中加入一个模式就可以使它变得更为灵活这两种活动都要求设计人员对模式有着全面的了解设计人员知道的越多他所选择的模式就越匹配通常可能会几种选择因此选择或标识的过程可能是一个做决策的问题这时设计模式的压力部分就起到指导的作用?步骤 2规划和分配把模式实例化的过程将引起以下问题在问题领域内模式的类是什么模式的类还应有什么其它任务在标识模式候选的情况下所引起的问题上给定的类操作和属性在模式中担任的是什么角色?步骤 3过滤把一个设计模式

37、实例化时有可能会改变它的原始结构有时改变或去掉某些类会减少模式原来的灵活性下面的例子中会有显示但是只要给模式实例编制恰当的文档就可以在必要的时候恢复原来的灵活性当在一给定的设计中插入一个模式时也可能会需要改变类的接口或增加新的类因此将由模式的抽象类来保持所需要的灵活性?步骤 4细化最后由技术类完成设计它们还会增加任何新的语义但把有关问题领域的考虑和技术问题以及编码问题分开 另外还可能需要对类的接口做一些扩展这些都完全由设计人员来决定了10.9 模式选择举例评估项目该项目的目标是开发一个面向对象的接口使 SAP-R/3 商业对象知识库和 Apple/IBM的开放脚本架构OSA之间可进行互操作OS

38、A 与 Microsoft 的 OLE 自动机类似 商业对象知识库是对商业对象的管理单元主要由 SAP 商业工作流程使用商业对象允许对 R/3 数据进行面向对象的接入和修改我们将以该项目中的存储商业对象类型和图10-16 中显示的过程控制作为例子图 10-16 OSA 服务器的组件10.9.1 实例化模式存储商业对象类型模式情景SAP 商业对象的类型是在商业对象知识库中定义和维护的这种类的接口由一组属性和操作组成而操作由一组参数组成问题开发一个单元来维护和保存类的接口解决根据数据的分层结构复合模式是一种可能的选择对该模式一种直接的实例化如图 10-18 所示原始的复合模式结构如图 10-17

39、所示压力考虑情景我们修改第一个选择把属性和参数分开没有必要因此把复合模式转换成设计继续考察模式的结构时发现根本没有叶类因此把复合类从抽象类变成具体类这样做虽然为了简单而降低了复合模式的灵活性但是如果需求发生变化时我们可以简单地再加上叶类恢复模式的灵活性 最后模式就可以工作了而保存参数等技术任务就落到类模板 List 和 Iterator 上了步骤 4图 10-17 首先尝试 Composite 模式图 10-18 实例化 Composite 模式的步骤10.9.2 标识模式候选过程控制的例子减弱子系统之间的相互影响是设计 OSA 的重要目标指定与 SAP R/3 和 OSA 交互的子系统被严格

40、分离开来目的是保证具有互操作性接口相互之间易于替换这种消弱的目标对数据流和控制流都做到了在本例中我们将围绕控制流进行讨论也就是对 OSA事件OSADispatch的响应图 10-19 是设计的一部分代表了一般问题在事件的接收方和表示 SAP 系统的 BOR 组件的类之间是如果维护控制流的下面就是需求的动机?来自快速原型的早期反馈放松子系统之间的耦合BOR 之间的过程控制?分析阶段推迟的需求认为不能改变 BOR 类所代表的 SAP 子系统OSADispatch应该很容易被其它有互操作性的接口如 OLE 等所取代?对分析阶段的需求进行扩展 OSADispatch 和 BOR 之间一对多的关系 使几

41、个 SAP系统可以被一个 OSA 事件同时找到这些需求的目的都是通过加入更多的灵活性来提高设计的质量从这个出发点我们对现有一些模式进行分析找出最适合的一个?Facade 封装了子系统并定义了一个通用化的接口使子系统更容易处理?Adapter 把一个类的接口转换成客户需要的?Chain of Responsibility 把一组接收对象链接到一个发送对象上请求将沿着接收方链传递直到有对象处理它?Observer 定义了一个主体Subject和一个或多个观察人Observers之间的一对多的相关确保当主体发生变化时所有的观察人都得到通报选择模式是应用模式过程中最重要的一步因为后面所有对设计的改变以

42、及最后的质量都依赖于它设计员必须依靠他对设计模式的知识以及他对问题需求的理解作出正确的选择而对模式的深入理解必须经过几次应用模式后才能得到图 10-19 的下面部分代表了 Observer 模式的核心?把组件的接口分成两部分一部分是不可改变的抽象耦合上面部分以及从ConcreteObserver 到 ConcreteSubject 的特定请求下面部分?主体和它的观察人之间一对多的关系?从直觉上看整个过程是按照顺时针进行的AttachTo()-Action()-Notify()-Update()-GetState()现在来分析一下我们所做的决定Facade 和 Adapter 不适合我们的情况因

43、为它们主要是结构模式OSADispatch 和 BOR 之间控制流的行为方面是最重要的Chain ofResponsibility 也不适合因为这个模式的本质在于对象具有沿着它们的类层次传递请求的功能把一个子系统的类组织成一个有继承关系的层次从语义上讲是没有道理的只是在设计插入一个模式没有任何意义最后 Observer 模式看起来最适合下面将讨论如何把它转换到设计中我们首先研究一下现有的设计 图10-19上面部分在接收到一个事件后 OSADispatch类把请求传给 BOR 接口因此BOR 起到服务器的作用而 OSADispatch 则是客户但这个方法的缺点很快就体现出来因为由 OSADisp

44、atch 负责控制通信和在几个 SAP 系统中进行选择 通过改变客户和服务器的角色就能使设计更为灵活因此把 OSA 服务器内的通信流逆转如图 10-20 所示现在 OSADispatch 的功能就成了服务器当接收到一个事件后它只是把通知的消息转发Notify()告诉说发生了改变所有连接到主体的 SAP 子系统都得到更新的消息并自己决定进行什么响应然后OSADispatch 会发一些其它请求GetCommand()模式是否匹配模式是否匹配模式是否匹配模式是否匹配抽象耦合抽象耦合抽象耦合抽象耦合削弱组件之间的耦合削弱组件之间的耦合削弱组件之间的耦合削弱组件之间的耦合过程过程过程过程图 10-19

45、步骤 1搜索正确的匹配在步骤 2 中 图 10-20很明显 BOR 类的整个接口 即 Create(),Delete(),and Invoke(),不能给它们分配模式的功能结果是我们把 BOR 的接口变成如图 10-21 所示这时客户就不能调用 BOR 以前的函数了它们成为保护成员函数它自己会通过调用 Update()进行控制最后在步骤 4图 10-21我们还插入了技术类如List和Iterator为了使 OSADispatch 更容易替换的Observer 模式的实例化只能作为一个框架实现为此将插入一个抽象消息调度员AbstractDispatch来定义 BOR 和 AbstractDisp

46、atch之间的通信协议在这之间通信是由 GetCommand()处理的具体的调度员如OSADispatch 将从主体和 AbstractDispatch 派生而来可应用 Adapter 模式把通信协议翻译过来这里的描述清楚地表明原来的方法变得灵活了同时责任也发生了转移映射出向框架开发的平滑过渡图 10-22图 10-20 步骤 2分配和规划图 10-21 步骤 3 和步骤 4过滤和细化图 10-22 角色的变化无缝地过渡到框架设计10.10 模式应用举例形状编辑器JohnsonHelmGamma 和 Vlissides 把设计模式分成三类 行为结构和创建的在这一节中 我们以一个作图工具为例 分

47、别举出这三种模式的例子 包括它们相应的 Java程序来说明设计模式的应用首先我们看一下这个工具的关键需求然后讨论如何用设计模式实现这些特殊需求它们是?同一个图的多种视图?删除Delete取消删除Undelete和重做Redo?用户可定义的复杂的复合形状?形状选择?使编辑器可扩展下面我们就讨论如何用模式来实现这些需求10.10.1 同一个图的多个视图任何作图工具都应该具备的一个功能就是允许一个模型有多个视图比如表格工具Excel 就允许对同一组数据有一个饼图视图一个条形图视图和一个表格视图并且如果数据更新的话那么这些视图都会自动更新在我们的作图工具中我们也希望能用一个以上的视图来描述底层模型如果

48、对其中一个视图的改变能自动地体现在其它视图中这样后来我们就能在 Diagram 类中加上新的视图但 Diagram 类必须能够知道这些视图从而当其中一个改变时它可以更新其它视图为这一问题提供解决方案的模式恐怕是最老的模式了这就是 Apple 称之为模型/视图/控制器的模式而在 Microsoft 的 MFC 中是模型/视图而在 Java 中是观察员/可观察的 接 口/类 对Gamma 等 称 之 为 观 察 员 模 式本 节 我 们 就 用 Java 的 术 语Observer/ObservableObserver/Observable 模式类是从 Observer 派生而来的负责描述模型通过

49、调用addObserver()注册并把它们自己加到 Observers 的清单中这个清单是由 Observable 派生而来的类在其内部维护的当 Observable 对象中的模型改变时它对 Observers 清单中的每一项 调用每个Observer的onUpdate()操作 Observer派生类为了响应对它的onUpdate()操作的调用查询模型Observable 派生的类并且更新它的显示 很明显Observer派生类知道 Observable 派生类但 Observable 派生类只需要知道它的 Observers 是Observer 类型的并且还定义了操作 onUpdate()在我

50、们的作图工具中Diagram 是 Observable 类如图 10-23 所示DrawShapes 类是唯一的 Observer 类Diagram 和 DrawShapes 代码分别见图 10-25 和 10-24 所示那为什么还要用模式呢答案就是为了可扩展性Observer/Observable(CLD00004.DAT)类型类图所在页 CLD最近修改时间24-Feb-97 18:14:29最近修改人小 E图 10-23 Observer/Observable类图/*/DrawShapes.java:Applet/*import java.applet.*;import java.awt.