从解决问题的角度讲设计模式非常好，特别是两个解决统一问题的设计模式一起讲。
有一个小错误：P67 setUp()写成了steUp()
敏捷宣言
我们一直在实践中揭示更好的软件开发方法，身体力行的同时也帮助他人。
由此，我们建立了如下价值观：
个体和互动 优先于 流程和工具
工作的软件 优先于 详尽的文档
客户合作 优先于 合同谈判
响应变化 优先于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。面向对象设计的原则
SRP 单一职责原则 就一个类而言，应该有且仅有一个引起它变化的原因。
OCP 开放-封闭原则 软件实体（类、模块和函数等）应可以扩展，但不可修改。
LSP 里氏替换原则 子类型必须能替换掉它们的基本类型。
ISP 接口隔离原则 不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。
DIP 依赖倒置原则 抽象不应该依赖于细节。细节应该依赖于抽象。
REP 重用发布等价原则 重用的粒度就是发布的粒度。
CCP 共同重用原则 一个包中的所有类应该是共同重用的。如果重用包中的一个类，那么就要重用包中的所有类。相互之间没有紧密联系的类不应该在同一个包中。
CRP 共同封闭原则 一个包中所有的类对同一类性质的变化应该是共同封闭的。一个变化若对一个包有影响，就会影响到包中所有的类，但不会影响到其他的包造成任何影响。
ADP 无依赖原则 在包的依赖关系中不允许存在环。细节不应该有其他依赖关系。
SDP 稳定依赖原则 朝着稳定的方向进行依赖。
SAP 稳定抽象原则 一个包的抽象程度应该和其他的保持一致。很多团队迷失在追求文档而非软件上。这通常是个巨大的错误。有条简单的规则称为“文档的马丁第一原则”，意在防止此类错误发生：
除非文档紧急且重要，否则不要写。“大千世界，唯一稀缺的是人类的注意力。”——凯文·凯利（KK）
每个软件模块都有三项职责。第一项职责是运行所完成的功能。这是该模块得以存在的原因。第二项职责是它要应对变化。几乎所有的模块在它们的生命周期中都要变化，开发者有责任保证这种改变应该尽可能简单。一个难以改变的模块是拙劣的，即便能够工作，也需要对它进行修正。第三项职责是要和读的人沟通。对该模块不熟悉的开发人员应该能够轻松地阅读并理解它。一个不能沟通的模块也是拙劣的，同样需要对它进行修正。
在 SRP 的语境中，我们把职责定义为“变化的原因”（a reason for change）。如果你有超过一个的动机去改变一个类，那么这个类就具有多种职责。有时，我们很难注意到这一点。我们习惯于以组（group）的形式去考虑职责。
许多开发人员可能会对“合理假设”的行为这一概念惴惴不安。怎样才能知道客户真正的要求呢？有一种技术可以让这些合理的假设明确下来，从而支持LSP。这种技术就是基于契约的设计（Design By Contract, DBC）。梅耶（Bertrand Meyer）对此做过阐述［Meyer1978, p.331］。
使用 DBC，类的作者明确表达出对于这个类的契约。客户端的代码可以通过契约获悉可以依赖的行为方式。契约是通过为每一个方法声明前置条件（precondition）和后置条件（postcondition）来制定的。要让一个方法得以执行，前置条件必须为真。执行完毕后，这个方法要保证后置条件为真。
按照梅耶（Meyer）的阐述，派生类的前置条件和后置条件的规则如下：
在重新声明派生类中的方法（routine，例程）时，只能使用相等或者更弱的前置条件来替换原始的前置条件，只能使用相等或者更强的后置条件来替换原始的后置条件。［Meyer97,p.573］
换句话说，当通过基类的接口使用对象时，用户只知道基类的前置条件和后置条件。
因此，派生类对象不能期望这些用户遵从比基类更强的前置条件。也就是说，他们必须接受基类可以接受的一切。同时，派生类必须和基类的所有后置条件一致。也就是说，它们的行为方式和输出不能违反基类已经确立的任何限制。基类的用户不能被派生类的输出干扰。包的设计原则
粒度：包的内聚性原则
重用发布等价原则（REP）
可以复用的粒度就是可以发布的粒度。
共同重用原则（CRP）
在包中的类可以一起被复用。如果你复用包中的某一个类，那么就要复用包中的
所有类。
共同封闭原则（CCP）
一个包中的类对于同一类型的变化应该是共同封闭的。对于一个包的更改会影响
到该包中的所有类，而不会影响到其他包。
稳定性：包耦合性的原则
无环依赖原则（ADP）
包之间的依赖关系图中不应该存在环形。
稳定依赖原则（SDP）
向着稳定的方向依赖。
稳定抽象原则（SAP）
包的抽象程度应该和其稳定程度一致。
