UML与设计模式.ppt

《UML与设计模式.ppt》由会员分享，可在线阅读，更多相关《UML与设计模式.ppt（37页珍藏版）》请在三一办公上搜索。

1、10.1,10.2,10.3,10.4,10.5,10.6,10.7,10.8,10.9,10.10,返回总目录,目,录,第 10 章 UML 与设计模式.2什么是模式.2为什么要使用设计模式.3模式的分类.4模式的组成元素.6模式的质量.7一个简单的模式例子 代理模式.8UML 对模式的支持.9应用设计模式进行系统设计.14模式选择举例 评估项目.15模式应用举例 形状编辑器.20,10.11,小,结.36,第 10 章,UML 与设计模式,过去几年 在面向对象领域中的一个重要突破就是提出了设计模式的概念 设计模式由于实用而受到欢迎 它们能够表达和重用专家技术和经验 能进行系统框架设计 在表

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

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

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

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

6、架构元素的描述 又是对如何以及何时创建该元素的规则 从本体论ontological 的观点来说 模式的 生成的 属性指模式的内容 content 即指反复出,现的事物的自身 从认识论 epistemological 的观点来说,描述的 属性指模式的形式,form 是我们捕捉并表述这一事物的方式 通过 问题 情况 压力 解决 的形式简而言之 设计模式的核心是问题描述和解决方案 问题描述说明模式的最佳使用场合以及它将如何解决问题 解决方案是用一组类和对象及其结构和动态协作来描述的10.2 为什么要使用设计模式在软件业中 设计模式是面向对象系统使用的一些可重用的已经得到了很好证明的巧妙 通用 简单的

7、设计解决方案 软件设计中的设计模式具有以下特性巧妙 设计模式是一些优雅的解决方案 一般很难立刻设计出来通用 设计模式通常不依赖某个特定的系统类型 程序设计语言或应用领域 它们是通用的得到了很好的证明 设计模式在实际系统和面向对象系统中得到广泛应用 它们并不仅仅停留在理论上简单 设计模式通常都非常小 只涉及很少一些类 为了构建更多更复杂的解决方案 可以把不同的设计模式与应用代码结合或混合起来使用可重用 设计模式的建档方式使它们非常易于使用 正如前面提到的 它们非常通用 因而可用于任何类型的系统 注意此处的可重用性是在设计层 而不是在代码层 设计模式平在类库中 只有系统架构使用它们面向对象 设计模

8、式是用最基本的面向对象机制如类 对象 通用化和多态等构造的那么 为什么要使用模式呢 首先 使用设计模式 就可以更准确地描述问题和它们,的解决方案 其次 使用设计模式可以具有一致性 consistency,即如果对一些已知的,问题我们有一类标准的解决方案 那么在遇到相同问题时 我们能够采取一致的方法 这就使代码更容易理解 使用设计模式的再一个原因就是 在遇到问题时 无需每次都从底,层做起 而是可以从标准解决方案,设计模式入手 并对它改编 使之适应特殊问题的,需要 这样就节省了时间 并且提高了开发的质量 模式为面向对象软件开发人员提供了以下机制根据实际系统的开发经验提供对共同问题的可重用的解决方案

9、提供类和对象级之上抽象的名称 通过设计模式 开发人员能够在更高的层次上讨论方案 例如 我建议我们可以用 Bridge 或 Adapter 来解决这个问题和 Adapter 是两种设计模式提供对开发的功能性和非功能性方面的处理方案 许多模式特别强调了某些面向对象设计擅长的领域 区分接口和实现 放松各部分之间的依赖性 隔离硬件和软件平台 并且具有重用设计和代码的潜能,提供了开发框架 framework 和工具的基础 在设计可重用框架时 设计模式是最基本的架构为面向编程和设计学习提供教育和训练支持 通过对设计模式的研究 能够深入理解良好设计的最基本性质 从而在后面的设计中加以模拟和应用10.3 模式

10、的分类不同的书籍和论文在描述设计模式时的方式各有差异 有的采用文本方式 有的采用文本和建模语言模型的方式 也有多种对模式的分类方法 四人组 书中定义了 23 种模式的分类 该书的文档风格现在成为定义新模式的模板 该书定义了以下几种模式分类创建模式 针对例程 包括创建什么对象 以及如何及何时创建 和类及对象的配置 允许系统中有不同结构和功能的 产品 对象 常见的创建模式有 AbstractFactory Factory Method Prototype Singleton Object Pool 图 10-1 是一个 Builder的例子,1:receive(msg:MIMEMsg),:Mess

11、ageManager,outMsg:OutboundMessageIF,new,1.2:send(),1.1:outMsg:=parse(msg:MIMEMsg)1.1.2:to(:String)1.1.3:from(:String)1.1.4:plainText(:String)1.1.5:jpegImage(:Image),builder:MAPIBuilder,1.1.6:outMsg:=getOutboundMsg(),:MIMEParser,1.1.1:builder:=getInstance(to:String)MessageBuilder,图 10-1,Builder 模式举例,

12、结构模式 针对在大的结构中使用类和对象的方式,并把接口与实现分离开来,1,1,),1,CacheManagerfetchObject(:ObjectKey,Cache-objects-for,CacheaddObject(:Object)fetchObject(:ObjectKey),1,cacher,1,Create-objects-for-cachingfetcherObjectCreatercreatObject(:ObjectKey),图 10-2,ObjectKeyCache Management 模式,Caches0.*Object,行为模式 针对在对象之间责任分配的算法 以及类和

13、对象之间的动态交互 行为模式不仅仅处理对象的结构 还处理它们之间的通信 Chain of ResponsibilityCommand Little Language/Interpreter Mediator Snapshot Observer State NullObject Strategy Template Method Visitor 图 10-3 是 Visitor 模式,1,Uses,0.*,ObjectStructure,1,Client,1,1,Uses,1,1,Uses,Uses,1,ConcreteVisitor1,ConcreteVisitor2,.,Contains,0.

14、*,Visitor#navigationOperation1():AbstactElement#navigationOperation2():AbstractElement.,navagates,AbstractElement,ConcreteElement1图 10-3 Visitor 模式,ConcreteElement2,.,格式,10.4 模式的组成元素Alexander 说 我们定义的每个模式 都应该以规则的形式 在情景 情景下产生的压力系统以及允许这种压力自我释放的配置之间建立关系 他还推荐使用图来描述模式Alexander 所使用的模式的描述格式称为 Alexandrian 方式

15、 在GoF中使用的称为 GoF不管模式的记录方式有多大的区别 它都应该包括一些本质的元素 以下是一些公认的模式基本元素名模式必须具有一个有意义的名 这样就可以用一个词或短语来指代该模式 以及它所描述的知识和结构 好的模式名组成讨论概念抽象的词汇表 有时 一种模式可能有多个公认的名字 这种情况下最好把它的绰号以及同义词在 别名 或 也作为 中列出 有的模式格式还提供模式的分类问题陈述问题并描述它的意图 它在给定的情景和压力下所要达到的目标和目的 通常压力是阻碍完成这些目的的情景,是问 题 以 及 它 的解 决 方 法 重 复发 生 的 前 置条 件,告 诉我 们 模 式 的 可应 用 性,app

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

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

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

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

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

21、象和精细层次上导致其它不同层次上的模式 或与它们复合,平衡 每个模式必须实现它的压力和约束之间的某种平衡 这种平衡可能来自用来使解决方案空间冲突最小化的一个或多个不变量和启发式 这种不变量通常代表了解决问题最基本的原则或思想 并解释了该模式中的每一个步骤 或规则,注意,总之,模式的目标是,通过把它的每一组成部分技巧性地组织起来,使它的整体和大,于部分和10.6 一个简单的模式例子 代理模式了解设计模式的最好办法就是去研究一个实际的模式 下面我们就以代理模式为例进行讨论代理模式是一个结构模式 把接口从实现中分离成不同的类 它的主要思想是用一个代理对象作为另一个真实对象的代理 由这个代理控制所有对

22、真实对象的接入 从而解决了当由于性质 位置或接入限制而使得真实对象无法被直接实例化的问题 这是一个非常简单的模式 但很容易说明 UML 是如何描述模式的 图 10-4 是 UML 中 Proxy 模式的类图,Client,SubjectRequest(),RealSubjectRequest(),ProxyRequest(),.,Request();,图 10-4,把 Proxy 设计模式描述成一个 UML 类图,Subject 是一个抽象类 因而是斜体,Proxy 模式涉及三个类 Subject RealSubject 和 Proxy 图中的 Client 类使用该模式使用抽象类 Subje

23、ct 中定义的接口 在 RealSubject 和 Proxy 中都实现了 Subject 定义的接口 RealSubject 实现了接口中的操作 而 Proxy 类则把它收到的所有调用都委托给RealSubject 去执行 由 Proxy 对象控制对 RealSubject 对象的接入 这一模式有以下几种应用场合更高的性能和效率 在需要真正的对象之间 系统可以用廉价的代理来减少耗费当在代理处调用操作时 它首先检查是否已经实例化 RealSubject 对象 如果没有就把它实例化并把请求委托给它 如果已经实例化了 则立即转发请求 这种方法在 RealSubject 对象的创建非常 昂贵 时很有

24、效 比如 必须读取数据库 复杂的初始化等 许多具有很长的启动时间的系统 通过使用 Proxy 模式可以显著地提高性能授权 如果需要检查调用方是否具有调用 RealSubject 对象的授权 则可以由 Proxy来完成 这时 调用方必须给出它自己的身份 Proxy 必须和某个授权对象通信是否允许接入,局部化 RealSubject 对象可以位于其它系统中 本地的 Proxy 只是在本系统中 扮演它的角色 而所有请求都被转发给其它系统 本地客户只看到 ProxyProxy 模式可以有许多种变形 如 完成其它功能无需全部委托给 RealSubject 可以改变参数的类型或操作的名词 或者做一些准备工

25、作来减少 RealSubject 的负荷 这些变形体现了模式背后的思想 模式是一种解决方案的核心 可以有多种变形 改装或扩展但不改变基本的方案在 四人组 的书中 是用类图描述模式的 用一个对象图和一个消息图 有点类似UML 中的序列图 很多地方是用文本来描述某些方面 如意图 动机 可应用性 结构协作 实现 举例的代码以及模式的结合 另外还包括同一模式其它的名字 有类似性质的相关模式以及已知的该模式的用法模式的代码通常都简单 根据需要把 RealSubject 实例化的 Proxy 类的 Java 代码很简单 如图 10-5 所示public class Proxy extends Object

26、RealSubject refersTo;public void Request()if(refersTo=null)refersTo=new RealSubject();refersTo.Request();,图 10-5,把 RealSubject 实例化的 Proxy 类的 Java 代码,10.7,UML 对模式的支持,在应用设计模式时 UML 非常重要所示,因为它允许模式作为架构的一部分 如图 10-6,图 10-6,在 UML 中模式的具体化,图中 Oberserver 是设计模式,同时还显示在,该模式的特定使用中出现的实际的类在 UML 中模式是用一个协作描述的 协作描述了情景和

27、交互 其中情景是指协作所涉及的所有对象 它们之间的相互关系 以及分别是哪个类的实例 交互显示了在协作中,对象完成的操作 发送消息以及相互调用,模式具有情景和交互 因此很适合用协作来,描述 事实上是用一个参数化协作来描述的图 10-7 中的虚椭圆就是模式的符号 里面是模式的名字 模式必须有名字 图 10-8是 Proxy 模式对象图 图中表明 Client 对象有一个链接是连到 Proxy 对象的 然后又连接到 RealSubject 对象上模式名,图 10-7,一个协作符号代表一个设计模式,aClient:Client图 10-8,aProxy:Proxy用对象图描述 Proxy 模式的情景,

28、aRealSubject:RealSubject,在描述 Proxy 模式时 交互显示了当客户提出请求时对象是如何交互的 图 10-9 中的序列图显示了如何把请求授权给 RealSubject 对象以及结果是如何返回给客户的协作图可以在同一个图中显示出情景和交互 图 10-8 的对象图中的情景以及图 10-9中的交互都体现在图 10-10 中的协作图中了 是否使用协作图或者分别表示在一个对象图和一个序列图中依情况而定 更复杂的模式可能需要描述几个交互来显示该模式不同的行为,aClient:Client,Request(),aProxy:Proxy,Request(),aRealSubject:

29、RealSubject,su,bj,ec,t,图 10-91:Request(),用序列图描述 Proxy 设计模式2:Request(),aClient:Client,aProxy:Proxy,aRealSubject:RealSubject,StaticsticsInterface,4:图 10-10,3:用协作图描述 Proxy 设计模式,Sales,Proxy,proxy,Sales,Staticstics,reals,ubje,ct,图 10-11,在一个类图中使用的 Proxy 模式,其中 Statistics Interface 类有 subject 参与,Sales 类有 pr

30、oxy,类参与 Sale Statistics 类有 realsubject 参与10.7.1 参数化协作前面提到 实际上是用参数化协作或一个模板模式描述模式的 参数可以是在实例化,模板时指定的类型 如类,关系或者操作 在一个参数化协作中 参数叫做参加人,participant,是类 关系或操作 设计模式参加人是模式定义的完成角色的应用元素,例如 在 Proxy 模式中的担任 Subject Proxy 和 RealSubject 类的类 在图中 参加人的表示是一个从模式符号与完成不同角色元素之间的一个相关性关联描述的 该相关性上标注了参加角色的名 说明了在设计模式中该类所扮演的角色 在 Pr

31、oxy 模式中 参加的角色是 Subject Proxy 和 RealSubject如果要扩展协作 则必须用参加的类显示出模式的情景和接口 图 10-11 有意识地使参加人的类名与它们所扮演的角色不同 以此表明它在模式中的任务是由相关中的角色名定义的 在实践中 通常都使类的名适合模式 例如 Sales 类叫做 SalesProxy SaleStatistics类叫做 SalesStatisticsSubject 类 等等 但是 如果已经定义了该类或它们参加了几种模式 就不能这样了 如果要对协作进行扩展 则显示出参加人在该模式中所 扮演 的角色 如图 10-12 所示,统,子,Client,Sa

32、les InterfaceSum(),Sales StatisticsSum(),SalesSum(),.,Sum();,数据库连接,图 10-12,用图 10-11 中的参加人扩展 Proxy 模式,子,系,统,类,数据库查询,子系统类,外观,数据库系统,Facade,数据库语句,系,类,引用图形窗口,观察人,Observer,主体,股票查询服务器,GetCurrentPrice()GetHistoricalPrices(),图 10-13,模式是生成子,这个类图显示了一组类,它们的部分情景和协作是用模式描述的,10.7.2 对使用模式的建议模式被定义成参数化协作 有自己的名字 比基本元素的

33、抽象级别高 代表了设计层的构造 在不同的设计中可以重复使用同一个模式 因为使用模式后 无需显示出系统的,人,察,体,主,观,所有部分 所以设计良好的模式可简化系统的描述 模式中的情景和交互是隐含的 因此可以把模式看作设计方案的通用化子 如图 10-13 所示在开发过程中 开发人员可以在图中扩展或隐藏模式所代表的情景和交互 用参加模式的类表示 UML 中用参数化协作来描述模式是很自然的 以下是一些使用设计模式的建议模式的名非常重要 模式的名是比模式中的设计元素抽象级别符号 设计模式的一个非常重要的性质就是能够在很高的抽象级别上进行通信和讨论确保项目中所有的人都了解模式 有的模式非常简单 很容易给

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

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

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

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

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

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

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

41、该模式一种直接的实例化如图 10-18 所示 原始的复合模式结构如图 10-17 所示压力 考虑情景 我们修改第一个选择 把属性和参数分开没有必要 因此把复合模式转换成设计 继续考察模式的结构时 发现根本没有叶类 因此 把复合类从抽象类变成具体类 这样做虽然为了简单而降低了复合模式的灵活性 但是如果需求发生变化时,我们可以简单地再加上叶类恢复模式的灵活性,最后,模式就可以工作了,而保存参数,等技术任务就落到类模板 List 和 Iterator 上了 步骤 4,图 10-17图 10-18,首先尝试 Composite 模式实例化 Composite 模式的步骤,10.9.2 标识模式候选,过

42、程控制 的例子,减弱子系统之间的相互影响是设计 OSA 的重要目标 指定与 SAP R/3 和 OSA 交互的子系统被严格分离开来 目的是保证具有互操作性接口相互之间易于替换 这种消弱的目标对数据流和控制流都做到了 在本例中 我们将围绕控制流进行讨论 也就是对 OSA,之,以及从,只是,事件 OSADispatch 的响应 图 10-19 是设计的一部分 代表了一般问题 在事件的接收方和表示 SAP 系统的 BOR 组件的类之间是如果维护控制流的 下面就是需求的动机来自快速原型的早期反馈 放松子系统之间的耦合 BOR 之间的过程控制分析阶段推迟的需求 认为不能改变 BOR 类所代表的 SAP

43、子系统 OSADispatch应该很容易被其它有互操作性的接口如 OLE 等所取代对分析阶段的需求进行扩展 OSADispatch 和 BOR 之间一对多的关系 使几个 SAP系统可以被一个 OSA 事件同时找到这些需求的目的都是通过加入更多的灵活性来提高设计的质量 从这个出发点 我们对现有一些模式进行分析 找出最适合的一个Facade 封装了子系统 并定义了一个通用化的接口 使子系统更容易处理Adapter 把一个类的接口转换成客户需要的Chain of Responsibility 把一组接收对象链接到一个发送对象上 请求将沿着接收方链传递 直到有对象处理它,Observer 定义了一个

44、主体 Subject,和一个或多个 观察人 Observers,间的一对多的相关 确保当主体发生变化时 所有的观察人都得到通报选择模式是应用模式过程中最重要的一步 因为后面所有对设计的改变以及最后的质量都依赖于它 设计员必须依靠他对设计模式的知识以及他对问题需求的理解作出正确的选择 而对模式的深入理解必须经过几次应用模式后才能得到 图 10-19 的下面部分代表了 Observer 模式的核心把组件的接口分成两部分 一部分是不可改变的抽象耦合 上面部分ConcreteObserver 到 ConcreteSubject 的特定请求 下面部分主体和它的观察人之间一对多的关系从直觉上看 整个过程是

45、按照顺时针进行的 AttachTo()-Action()-Notify()-Update()-GetState()现在来分析一下我们所做的决定 Facade 和 Adapter 不适合我们的情况 因为它们主要是结构模式 OSADispatch 和 BOR 之间控制流的行为方面是最重要的 Chain ofResponsibility 也不适合 因为这个模式的本质在于对象具有沿着它们的类层次传递请求的功能 把一个子系统的类组织成一个有继承关系的层次从语义上讲是没有道理的,在设计插入一个模式,没有任何意义 最后,Observer 模式看起来最适合 下面将讨,论如何把它转换到设计中我们首先研究一下现有

46、的设计 图 10-19 上面部分 在接收到一个事件后 OSADispatch类把请求传给 BOR 接口 因此 BOR 起到服务器的作用 而 OSADispatch 则是客户 但这个方法的缺点很快就体现出来 因为由 OSADispatch 负责控制通信和在几个 SAP 系统中进行选择 通过改变客户和服务器的角色 就能使设计更为灵活 因此 把 OSA 服务器内的通信流逆转 如图 10-20 所示 现在 OSADispatch 的功能就成了服务器 当接收到,一个事件后 它只是把通知的消息转发 Notify(),告诉说发生了改变 所有连接到主,体的 SAP 子系统都得到更新的消息 并自己决定进行什么响

47、应 然后 OSADispatch 会发一些其它请求 GetCommand(),模式是否匹配抽象耦合过程削弱组件之间的耦合,图 10-19,步骤 1,搜索正确的匹配,在步骤 2 中 图 10-20 很明显 BOR 类的整个接口 即 Create(),Delete(),and Invoke(),不能给它们分配模式的功能 结果是 我们把 BOR 的接口变成如图 10-21 所示 这时客户就不能调用 BOR 以前的函数了 它们成为保护成员函数 它自己会通过调用 Update(),进 行 控 制 最 后 在 步 骤 4 图 10-21,我 们 还 插 入 了 技 术 类 如 List 和,Iterato

48、r为了使 OSADispatch 更容易替换的 Observer 模式的实例化只能作为一个框架实现,为此 将插入一个抽象消息调度员 AbstractDispatch,来定义 BOR 和 AbstractDispatch,之 间 的 通 信 协 议 在 这 之 间 通 信 是 由 GetCommand()处 理 的 具 体 的 调 度 员 如OSADispatch 将从主体和 AbstractDispatch 派生而来 可应用 Adapter 模式把通信协议翻译过来 这里的描述清楚地表明 原来的方法变得灵活了 同时责任也发生了转移 映射出向框架开发的平滑过渡 图 10-22,图 10-20,步骤

49、 2,分配和规划,图 10-21,步骤 3 和步骤 4,过滤和细化,图 10-22,角色的变化,无缝地过渡到框架设计,10.10 模式应用举例 形状编辑器Johnson Helm Gamma 和 Vlissides 把设计模式分成三类 行为 结构和创建的在这一节中 我们以一个作图工具为例 分别举出这三种模式的例子 包括它们相应的 Java程序 来说明设计模式的应用 首先我们看一下这个工具的关键需求 然后讨论如何用设计模式实现这些特殊需求 它们是同一个图的多种视图删除 Delete 取消删除 Undelete 和重做 Redo用户可定义的复杂的复合形状形状选择使编辑器可扩展下面我们就讨论如何用模

50、式来实现这些需求10.10.1 同一个图的多个视图任何作图工具都应该具备的一个功能就是允许一个模型有多个视图 比如表格工具Excel 就允许对同一组数据 有一个饼图视图 一个条形图视图和一个表格视图 并且如果数据更新的话 那么这些视图都会自动更新 在我们的作图工具中 我们也希望能用一个以上的视图来描述底层模型 如果对其中一个视图的改变能自动地体现在其它视图中这样后来我们就能在 Diagram 类中加上新的视图 但 Diagram 类必须能够知道这些视图从而当其中一个改变时 它可以更新其它视图为这一问题提供解决方案的模式恐怕是最老的模式了 这就是 Apple 称之为模型/视图/控制器的模式 而在