grasp更多具有职责的对象

1、第25章 GRASP更多具有职责的对象GRASP: More Objects with Responsibilities目标 学习使用其余的GRASP模式 多态（Polymorphism） 纯虚构（Pure Fabrication） 间接性（Indirection） 防止变异（Protected Variations）多态（Polymorphism）模式名：模式名：多态（Polymorphism）问题：问题：如何基于类型选择？如何创建可插拨的软件构件？解决方案：解决方案：当相关的或行为随类型（类）有所不同时，使用“多态操作”为变化的行为类型分配职责 。推论：推论：不要测试对象的类型，也不要使用

2、条件逻辑来执行基于类型的不同选择图25-1 使用多态适配不同的外部税金计算器NextGen问题：如何支持第三方税金计算器图25-2 对Monopoly问题应用多态Monopoly问题：如何设计不同的方格活动在图25-3和图25-4中用非正式的方法表示多态情形图25-3 应用多态性发送消息到接口发送消息到接口每种类型都有不同的landon(p)实现见图25-4到25-7图25-4 GoSquare的情形RegularSquare的情形图25-5 RegularSquare的情形IncomeTaxSquare的情形图25-6 IncomeTaxSquare的情形GoToJailSquare情形图2

3、5-7 GoToJailSquare的情形多态（Polymorphism）-讨论 容易加入新变种（新的种类） 可以引入新的实现而不会影响客户对象优点： 防止变异（Protected Variations） 许多设计模式依赖于多态（Polymorphism）。包括适配器（Adapter）命令（Command）组成（Composite）代理（Proxy）状态（State）和策略（Strategy）模式。相关模式：纯虚构（纯虚构（Pure Fabrication）模式名：模式名：纯虚构（Pure Fabrication）问题：问题：为了让设计更清晰而不想破坏高内聚性和低耦合，应采用什么方案呢？解决方

4、案：解决方案：分配这组高度内聚的职责给一个人造类。人造类不代表问题领域的任何事物，只是为了支持高内聚、低耦合和可重用而虚构的一个类。NextGen问题：在数据库中保存Sale对象假设需要保存一个假设需要保存一个SaleSale的实例到一个关系数据库，这个职的实例到一个关系数据库，这个职责该分配给谁？责该分配给谁？这个纯虚构解决了以下设计问题：这个纯虚构解决了以下设计问题： Sale 保持了具有高内聚和低耦合的良好设计保持了具有高内聚和低耦合的良好设计 PersistentStorage 本身的职责相对内聚，具有存储或插入对象到本身的职责相对内聚，具有存储或插入对象到持久化存储介质的单一性目的持

5、久化存储介质的单一性目的 PersistentStorage 是一个非常一般的和可重用的类是一个非常一般的和可重用的类根据信息专家模式，保存Sale的实例的职责可以分配给Sale本身。但是，会导致高内聚，低耦合和难以复用。Monopoly问题：处理骰子图25-8 关于Cup的DCD旧方案：Player滚动所有的骰子并且计算总点数。旧方案的缺点：1.计算总点数的服务无法用于其它游戏。 2. 不再次滚动骰子，则不能获知当前骰子总点数。新方案：引入纯虚构对象“骰盅”（Cup）在Monopoly游戏中使用Cup图25-9 在Monopoly游戏中使用Cup对象设计的讨论设计的对象大致可分为两类：设计的

6、对象大致可分为两类： 通过具有代表意义的分解(representational decomposition)而设计对象 代表问题域（或与问题域相关）的事物 - 领域模型中的概念类 通过行为的分解(behavioral decomposition)而设计对象 为了聚合某些公共的行为而构造的类，从功能方面划分职责。纯虚构通常基于相关的功能性进行划分，是一种以功纯虚构通常基于相关的功能性进行划分，是一种以功能为中心的或行为的对象能为中心的或行为的对象间接性（Indirection）模式名：模式名：间接性（Indirection）问题：问题：为了避开两个或多个事物之间直接耦合，该在如何分配职责？如何使

7、对象解耦，以支持低耦合并提高利用性潜力？解决方案：解决方案：将职责分配给中介对象，使其作为其他构件或服务之间的媒介，以避免它们之间的直耦合。中介实现了其它构件之间的间接性。示例：示例：如何避免如何避免Sale和和TaxMasterSystem之间直接耦合呢之间直接耦合呢也可能是：也可能是：SOAP over HTTP图25-10 通过适配器实现间接性示例：如何将Sale和关系数据库解耦 通过引入PersistentStorage类作为Sale和数据库之间的中介，对它们进行解耦。这也是间接性的一个例子。防止变异（Protected Variations）模式名：模式名：防止变异（Protecte

8、d Variations）问题：问题：如何设计对象、 子系统和系统，使内部的变化或不稳定性不会对其他元素产生不良影响？解决方案：解决方案：识别预计变化或不稳定之处，分配职责用以在这些变化之外创建稳定接口。注：通过增加一层间接性，即接口。内部对象只与稳定的接注：通过增加一层间接性，即接口。内部对象只与稳定的接口协作。这实现了隐藏外部系统的变化。口协作。这实现了隐藏外部系统的变化。该图显示了变化被保护，变化点是外该图显示了变化被保护，变化点是外部税务计算系统的部税务计算系统的APIs(有不同的接口有不同的接口)。图25-1 使用多态适配不同的外部税金计算器示例：ITaxCalculatorAdap

9、ter接口实现了防止外部税金计算器的变异关于“防止变异”的讨论 “防止变异”是非常重要和基本的软件设计原则。大部分设计原则和模式都是防止变异的机制（特例）。如：多态、接口、间接性、数据封装、大部分GoF设计模式等。 PV是一个根本原则，其促成了大部分编程和设计的机制和模式，用来提供灵活性和防止变化。包括数据、行为、硬件、软件构件、操作系统等的变化。 就某种程度而言，从以下面可以发现开发者或架构师的成熟度 不断地增长更多实现PV机制的知识 选择值得解决的适宜的PV问题 选择恰当的PV解决方案的能力源于防止变异的机制1 数据驱动设计 涵盖了一大族技术，包括读取来自外部的代码、值、类文件路径、类名等

10、。用以在运行时以某种方式改变或“参数化”系统。 其它变化因素还包括样式表、对象-关系映射元数据、属性文件、读取窗口布局等。 通过外置、读取并判断这些变化因素，能够防止数据、元数据或说明性变量对系统造成的影响 服务查询 包括使用命名服务（如Java JDNI）或用来获取服务的经纪人（例如Java Jini或Web Service的UDDI）等技术 通过使用查询服务的稳定接口，客户能够避免服务位置变化的影响。 这是数据驱动设计的一个特例源于防止变异的机制2 解释器驱动的设计 包括：读取并执行外部规则的规则解释器，读取并运行程序的脚本或语言解释器器、虚拟机、执行网络的神经网络引擎、读取并分析约束集的

11、约束逻辑引擎等。 这种方式能够通过外部逻辑表达式变更或参数化系统行为。 系统通过外置、读取、解释逻辑而避免了逻辑变化的影响。 反射或元级的设计 如：Java的反射机制。使用java.beans.Introspector以获取BeanInfo对象，并为bean的X属性请求getter方法的Method对象，然后调用Method.invoke。 通过使用自省-元语言服务的反射算法，系统可以避免逻辑或外部代码变化的影响。 该方法可视为数据驱动设计的特例。源于防止变异的机制3 统一访问 诸如Ada,Eiffel和C#等语言支持语法构造，以便能以一种方式同时表示方法和字段的访问。 可以将公共字段变为访问

12、方法，而无需改变客户代码 标准语言 如SQL等官方语言标准为各种语言的繁衍提供了限定保护 Lisko规换原则（LSP） 用子类或实现类（S）的对象替换父类或其它实现类（T）的对象，引用类型T的软件应该正常或按照预期工作。警告：预测PV和选择你的战斗 两个变更点 变化点：现有、当前系统或需求中的变化，例如必须支持多个税金计算器接口 进化点：预测将来可能会产生的变化点，但并不存在于现有需求中。 如果实际需要灵活性和对变化预防，那么就应该应用PV。如是如果预测将来验证或预测“复用”的可能性十分不确定，则需要有克制和批判的态度。 初学者倾向于脆弱的设计，而中等程度的开发者倾向于过度想象的、灵活的、一般化的设计。专家级的开发者会理智也进行选