《设计模式解析》摘录（4）

对象

    传统看法：具有方法的数据（从实现的视角来看待对象，太简单，太肤浅了）；

    新看法：具有责任的实体。这些责任定义了对象的行为（从概念视角出发）。

    关注动机而非实现，使设计模式中反复出现的主题，因为将实现隐藏在接口之后，实际上是将对象的实现与使用它们的对象解耦了。

封装

    封装不仅仅是数据隐藏；封装应该被视为“任何形式的隐藏”，可以是隐藏数据，但还可以隐藏实现细节，派生类设计细节，实例化规则。

    设计模式用继承对行为进行分类。

    发现变化并将其封装。

    考虑你的设计中哪些地方可能变化。这种方式与关注会导致重新设计的原因相反。它不是考虑什么会迫使你的设计改变，而是考虑你怎样才能够在不重新设计的情况下进行改变。这里的关键在于封装发生变化的概念，这是许多设计模式的主题。

    很多设计模式都使用封装在对象之间创建层。这样设计者可以在层的两侧进行修改，而不会对另一侧产生不良影响。这有利于两侧的松耦合。

    当一个类处理越来越多的不同变化（比如通过开关变量）时，代码的内聚性就会变地很差。也就是说，它所处理的特殊情况越多，可理解性就越差。

    用对象处理行为上的变化。用对象的属性来包含变化，和用对象的行为包含变化其实非常相似。

    共性分析寻找的是不可能随时间而改变的结构，而可变性分析则要找到可能变化的结构。可变性分析只在相关联的共性分析定义的上下文中才有意义......从架构的视角看，共性分析为架构提供长效的要素，而可变性分析则促进它适应实际使用所需。

    如果变化是问题领域中各个特定的具体情况，共性就定义了问题领域中将这些情况联系起来的概念。

    规约视角与概念视角之间的关系：规约标识了用来处理此概念所有情况（即概念视角所定义的共性）所需的接口。

    规约视角与实现视角之间的关系：对于给定的规约，怎样实现这个特定情况。

    敏捷方法要求代码具有可变性，而模式能够产生灵活的代码。这只是方法上的不同，而非道之不同。两种方法都要求代码具备同样的品质，它们只是殊途同归罢了。

    无冗余：某个规则只在一个地方实现；一个规则，一个地方。

    冗余与耦合之间往往纠缠不清。为避免耦合，代码需要封装在定义明确的接口之后。