高级软件架构设计.ppt

*命令（command）模式康凯意图将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。别名动作(Action)，事务(Transaction)动机有时必须向某对象提交请求，但并不知道关于被请求的操作或请求的接受者的任何信息。例如，用户界面工具箱包括按钮和菜单这样的对象，它们执行请求响应用户输入。但工具箱不能显式的在按钮或菜单中实现该请求，因为只有使用工具箱的应用知道该由哪个对象做哪个操作。而工具箱的设计者无法知道请求的接受者或执行的操作。命令模式通过将请求本身变成一个对象来使工具箱对象可向未指定的应用对象提出请求。这个对象可被存储并像其他的对象一样被传递。这一模式的关键是一个抽象的Command类。*其它设计模式VISITOR模式该系列中的模式如下:VISlTOR模式ACYCLICVISITOR模式DECORATOR模式EXTENSIONOBJECT模式是一个常见的问题：例如,有一个Modem对象的层次结构。基类中有所有调制解调器的公共方法。派生类代表不同调制解调器类型的驱动程序。假设需要向该层次结构中增加一个新方法confrgureForUnix。使之可在UNIX下工作。在每个调制解调器派生类中该函数的实现都不相同。（假设每个不同的调制解调器在UNIX中都有自己独特的配置方法和行为特征）。12必须针对所使用的每一种新操作系统都要向Modem层次结构中增加一个新方法?这种做法是丑陋的：我们永远无法封闭Modem接口。每当出现一种新操作系统时,就必须更改该接口并重新部署所有的调制解调器软件。3问题：直接增加configureForUnix方法其实回避了一个问题：对于Windows如何处理?MacOS?Linux?VISTTOR模式的一个非常常见的应用是,遍历大量的数据结构并产生报表。这使得数据结构对象中不含有任何产生报表的代码。如果想增加新报表,只需增加新的访问者,而不需要更改数据结构中的代码。这意味着报表可以被放置在不同的组件中,并且仅被那些需要它们的客户单独使用。整理分析类分析类是这样的类：它代表问题域中的简洁抽象；分析类映射到真实世界的业务概念（并且据此仔细命名）。问题域是首先产生软件系统（以及从此而来的软件开发活动）需求的域。通常，这是特定的业务领域，如在线销售或者客户关系管理。然而，务必注意，问题域可能根本不是任何特定业务活动，但是可能产生需要软件在其上运转的一块物理硬件─这是嵌入式系统。基本上，所有业务软件开发服务于某种业务需求，自动化一个已有业务过程或者开发具有有意义的软件组件的新产品。同样，向ShoppingBasket中添加如下职责：04显示购物篮中的商品。这是内聚的职责集合，一切都是为了维护客户选择的商品集合。它是内聚的，因为所有的职责都朝着相同的目标─维护客户已经选择的商品集合。实际上，我们能够把这些职责概括为非常高级层次的职责“维护购物篮”。05职责是类和它的客户之间的契约或者是类对它的客户的义务。本质上，职责是类提供给其他类的服务。分析类具有直接同类（由它的名称所表达）的目的相一致的以及直接同该类正在建模的真实世界“事物”相一致的非常内聚的职责集合，这一点是至关重要的。例如ShoppingBasket示例，你将期望该类具有如下职责：01从购物篮删除商品；03向购物篮添加商品；02验证信用卡；接收付款；打印收据。但这些职责似乎同购物篮的目的或直觉语法不匹配。它们不是内聚的，显然应该赋予其他什么类─可能是类CreditCardCompany、类Checkout以及类ReceiptPrinter。把职责适当地分配给分析类以最大化每个类中的内聚性，是很重要的。最后，良好的类与其他类之间具有最低数目的耦合。我们以给定类与其他类具有关系的数目来度量类间的耦合度。类间职责的平均分布趋向于产生低耦合度。把控制或职责局限于单一的类趋向于增加到该类的耦合度。以下是创建形式良好的分析类的一些经验法则。01每个类大约3~5个职责─典型地，类应该保持尽可能简单，这通常限制类能够支持的3~5个职责的数目。先前ShoppingBasket的示例是带有小的和可管理数目职责的专注的类的好的示例。02不存在独立的类─好的OO分析和设计的精华是，类相互协作让用户受益。同样，每个类应该同小部分类协作以提供所期望的功能。类可以把它们的一些职责托付给专注于特定功能的其他“辅助”类。03当心很多非常小的类─有时很难取得正确的平衡。如果模型看起来具有大量的非常小的类，每个类都具有一个或者两个职责，那么你应该仔细查看以把一些小的类整合成更