(零雨其蒙原创 转载请注明)
2007
年
3
月
9
日星期五
第
23
章
迭代
2
：更多模式
在前面学习用例的时候，已经知道一个用例包含多个场景（主成功场景和扩展场景），由于
UP
倡导的是增量式开发，因此
Larman
给出了一些建议：在多次迭代中对同一用例的不同场景或特性进行工作，并且逐渐地扩展系统以最终实现对所有功能需求的处理。但是，不应该把一个场景分开在多次迭代中处理
,
一次迭代应该完成一个或多个端到端的场景。（
P294
）
即一个用例可以分多次迭代完成（每次至少完成一个场景），一个场景必须在一次迭代中完成
第
24
章
快速地更新分析
P297
使用
UP
的过程成熟标志是
，知道何时创建制品能够带来显著价值，或是当遇到呆板的“完成作业”式的步骤时能够较好地略过。
创建子类的准则
当遇到下列情况时，创建超类的概念子类：
1）
子类具有我们感兴趣的额外属性
2）
子类具有我们感兴趣的额外关联
3）
对子类概念的影响、处理、反应和操作与超类或其他子类有显著的差异
关于子类和超类的其他准则（这些都是基于领域模型的讨论，也就是在分析时观点）
准则
：将超类声明为抽象类。虽然这是与软件无关的概念观点，但是也是常用的
OO
准则，即所有软件超类都是抽象的
准则
：在子类上附以超类名称。（如超类是
Square
，则子类名就是
GoSquare
，
RegularSquare
等）
第
25
章
GRASP
：更多具有职责的对象
在这一章中
larman
介绍了前面没有介绍过的四个
GRASP
模式：多态、间接性、纯虚构和防止变异。经过这章的学习之后，
GRASP
的
9
个模式就学全了
~
按照
Larman
的说法，那时我们就拥有了讨论设计的丰富、共享的词汇。
Polymorphism
多态
问题：
如何处理基于类型的选择？如何创建可插拔的软件构件？
解决方案：
当相关选择或行为随类型（类）有所不同时，使用多态操作为变化的行为类型分配职责。
推理：
不要测试对象的类型，也不要使用条件逻辑来执行基于类型的不同选择。
多态使我们不再使用条件分支语句来解决条件变化问题，前面在学习
Martin Fowler
的《重构》时我回忆了那个地磅系统中让人恶心的
case
和
if-else
逻辑程序段，它制造了大量的重复和让人感到对于业务过程的不解，从我个人的实践来看，多态可以很好的解决这一问题，因为复杂性被封装在了超类和子类的继承关系中——那时我在做一个搜索引擎时，使用多态避免了传统的使用条件分支语句来处理选择搜索类别的问题（按商品名称搜索，按作者搜索等类别），它有两点好处：一个是简洁，一个是清楚。可以很轻易的看出其逻辑关系。因此废弃条件分支语句吧，在
[
问题
]
中
Larman
实际上已经给出了使用多态的好处，只不过用的是问句。
P305
当对象
A
持续需要对象
B
中的数据时，意味着：
1
）对象
A
不应该持有该数据；或
2
）对象
B
而不是对象
A
应该具有这一职责（基于专家模式）。
Pure Fabrication
纯虚构
问题：
当你并不想违背高内聚和低耦合或其他目标，但是基于专家模式所提供的方案又不合适时，哪些对象应该承担这一职责。
解决方案：
对人为制造的类分配一组高内聚的职责，该类并不代表问题领域的概念——虚构的事物，用以支持高内聚、低耦合和复用
P308-309
信息专家所支持的目标是，将职责与这些职责所需信息结合起来赋予同一个对象，以实现对低耦合的支持。如果滥用纯虚构，会导致大量行为对象，其职责与执行职责所需的信息没有结合起来，这样会对耦合产生不良影响。其通常征兆是，对象内的大部分数据被传递给其他对象用以处理
（即该对象大量调用其它对象的方法来处理其自身的数据）。
Indirection
间接性
问题：
为了避免两个或多个事物之间直接耦合，应该如何分配职责？如何使对象解耦合，以支持低耦合并提高复用性潜力？
解决方案：
将职责分配给中介对象，使其作为其他构件或服务之间的媒介，以避免它们之间的直接耦合。中介实现了其他构件之间的间接性。
Protected Variation
防止变异
问题：
如何设计对象、子系统和系统，使其内部的变化或不稳定不会对其他元素产生不良影响？
解决方案：
识别预计变化或不稳定之处，分配职责用以在这些变化之外创建稳定的接口。注意：这里使用的“接口”指的是广泛意义上的访问视图，而不仅仅是诸如
Java
接口等字面含义。