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

    短期的抄近路，可能会在长期导致问题严重复杂化。灾难往往是由短期未臻最优的决策，长期积累而引起的。许多项目只关心处理眼前的紧迫需求，却不顾将来的维护。

    1、针对接口进行编程，而不要针对实现编程；

    2、优先使用对象组合，而不是类继承；

    3、考虑设计中什么应该是可以变化的。这种方法与关注引起重新设计的原因刚好相反。它不是考虑什么会迫使设计发生改变，而是考虑什么能够在不引起重新设计的前提下改变。这时主要关注的就是对变化的概念进行封装，这是许多设计模式的主题。

    特化技术最终总是会产生太深的继承层次。糟糕的是：继承层次太深将导致程序难以理解（弱内聚）、存在冗余、难以测试而且多个概念耦合在一起。

    尝试“考虑设计中什么应该是可以改变的”、“对变化的概念进行封装”，并且最重要的是“优先使用对象聚集，而不是类继承”。根据这种方法，应该这样做：

    1、寻找变化，并将它封装在一个单独的类中；

    2、将这个类包含在另一个类中。

    将某个变化的行为从使用它的类中移出来，这种过程与数据库中的规范化过程非常相似，在后一种过程中，需要将移到自己的表中，使用外键引用它们。