从解决问题的角度讲设计模式非常好,特别是两个解决统一问题的设计模式一起讲。
有一个小错误: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)
包的抽象程度应该和其稳定程度一致。