摘抄于Marhin Fowler《分析模式---可复用的对象模型》
模型无好坏对错之分,只有好用或者不好用之分。
概念模型是与接口(类型)而不是与实现(类)相关联的。
模式是起点,而不是终点。
设计一个模型时应使该模型中最频繁修改的部分所影响的类型数量达到最少。
只要为一个拥有超类型的类型定义了特征,就应该考虑将这些特征放在超类型上是否有意义。
将模型清楚地分解成操作级和知识级。
多个属性与可能会在几个类型中使用的行为相关时,就把这些属性组合成新的基础类型。
操作级中的对象会经常发生变化。它们的配置由很少发生变化的知识级来约束。
如果某个类型拥有多种相似的关系,可以为这些关联对象定义一个新的类型,并建立一个知识级类型来区分它们。
要记录一个值的变更历史,可以为这个值设立一个帐目。
在使用帐目时要遵守守恒原理:需要清算的物品不能凭空生成和消失,它仅仅是从一个地方转移到另一个地方。这使得发现和防止不守恒变得容易。
为了确定计算是如何进行的,把计算的结果表示成对象,由它来记住是由哪个计算产生的结果以及计算所使用的输入值是什么。
交易
当可以提供不止一个的等价特征集合时,就挑选领域专家最满意的一种方法。如果领域专家感到两种方法都有价值,那么就两种都显示并且把其中一个标记为派生的。
把一个特征标记为派生是对接口的一种约束,但不会影响基础的数据结构。
如果一组对象可以用不同的标准来组织,就应当使用合同夹。
当把一个过程看作类型的一个特征时,应该给这个过程提供一个抽象的接口,使得实现能轻松的通过子类化而改变。一个通过硬编码得到的实现是一个子类,不同的参数驱动方法是其他的子类。
当多重属性和一个可能在几个类型中使用的行为进行交互时,属性应该被结合成一个新的基本类型。
如果超类的适用领域狭窄而子类的适用领域广泛,就不应该使用泛化。
如果两个相类似类型的差异经常被忽略,那么一个抽象超类型就可以被使用。如果它们之间的差异通常是很重要的,那么一个抽象的超类型就不应该被使用。
如果一个抽象类型从不需要客户花费更多的努力来使用,那么它就应该被提供。
场景应该在价格或者汇率的组合需要被看作一个整体的时候使用。
为了把一个过程看作类型的一个特征,这个过程应该采用一个抽象的接口,以便实现能轻松的通过子类化而改变。一个通过硬编码得到的是现实一个子类,不同的参数驱动方法是其他的子类。
当信息可以从一个信息源检索或者可以从其他可用的数据计算时,应该提供一个抽象的接口,而源和计算各为一个子类。
派生合同
日期计算经常受到需要跳过的假日的影响。不同国家之间的假日通常是不同的,甚至不同商业机构也有自己的假日。
派生标志应该被用来定义从模型中其他的结构中派生的术语。
标记一个特征为派生是接口上的约束。他并不影响基础的数据结构。
当面对可选择的方法时,首先要选择最简单的,并当需要时改为更复杂的方法。
当可选择模型之间的选择余地很小时,听从领域专家的直觉。
只有当所有超类型的特征适合于超类型并且从概念上讲每一个子类型的实现是一个超类型的实例有意义时才应该使用子类型化。
当客户眼中的一个交易在交易人眼中是多个交易时,都可以使用产品/合同这种划分。
不要复制有相同内涵的基础关联。遵循这个原则导致责任分明的类型。
在责任分配中保持一致。提防一种类型有时对某事负责而有时又将这个责任委托给别的类型。(这种行为可能是正确的,但是他总是值得怀疑。)
关于状态图的泛化结果不能被很好的理解。确保关于超类型的所有事件可以由子类型来操作是很重要的。任何可被子类型化的状态图必须准许未知的事件。
后置条件定义对象在操作之后必须为真的条件。后置条件没有提到的其他改变都可以发生。
交易包
单向关联和双向关联之间的决定是减少相关类型的开发者的工作(通过减少类型间的耦合)和为类型的使用者提供方便之间的折中。
如果一个包只需要对另一个包的一部分的可见性,那么考虑将后面的包分成两个相互可见的包。
设计模板
设计模板定义软件构件的接口并且提出实现这些构件的建议。