《敏捷软件开发》读书笔记3

1、  如果一个类承担的职责过多，就等于把这些职责耦合在了一起。一个职责的变化可能会削弱或者抑制这个类完成其他责任的能力。这种耦合会倒置脆弱的（fragile）设计，当变化发生时，设计会遭受到意想不到的破坏。P88

 

2、  在SRP中，我们把职责定义为“变化的原因”（a reson for change）。P89

 

3、  变化的轴线仅当变化实际发生时才具有真正的意义。如果没有征兆，那么去应用SRP，或者任何其他原则都是不明智的。P90

 

4、  任何系统在其生命周期中都会发生变化。如果我们期望开发出的系统不会在第1版后就被抛弃，就必须牢牢地记住这一点。P92

 

5、  怎样可能在不改动模块源代码的情况下去更改它的行为呢？怎样才能在无需对模块进行改动的情况下就改变它的功能呢？P93

答案：关键是抽象（或者接口）。

 

6、  既然不可能完全封闭，那么就必须有策略地对待这个问题。也就是说，设计人员必须对于他设计的模块应该对那种变化封闭做出选择。他必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离那些变化。P97

 

7、  这一点不容易做到。因为它意味着要根据经验猜测那些应用程序生长历程中有可能遭受的变化。如果开发人员猜测正确，他们就获得成功。如果他们猜测错误，他们会遭受失败。并且在大多数情况下，他们都会猜测错误。P98

 

8、  遵循OCP的代价也是昂贵的。创建正确的抽象是要花费开发时间和精力的。同时，那些抽象也增加了软件设计的复杂性。开发人员有能力处理的抽象的数量也是有限的。显然，我们希望把OCP的应用限定在可能会发生的变化上。P98

 

9、  我不希望设计背着许多不必要的抽象。通常，我们更愿意一直等到确实需要那些抽象时再把它放置进去。P98

 

10、              为了防止软件背着不必要的复杂性，我们会允许自己被愚弄一次。这意味着在我们最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化。简而言之，我们愿意被第一颗子弹击中，然后我们会确保自己不再被同一只枪发射的其他任何子弹击中。P98

 

11、              刺激变化——如果我们决定接受第一颗子弹，那么子弹到来的越早、越快就对我越有利。我们希望在开发工作展开不久就知道可能发生的变化。查明可能发生的变化所等待的时间越长，要创建正确的抽象就越困难。P98

 

12、              在许多方面，OCP都是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处（也就是，灵活性、可重用性以及可维护性）。然而，并不是说只要使用一种面向对象语言就是遵循了这个原则。对于应用程序中的每个部分都肆意地进行抽象同样不是一个好主意。正确的做法是，开发人员应该仅仅对程序中呈现出频繁变化的那些部分做出抽象。拒绝不成熟的抽象和抽象本身一样重要。P101

 

13、              一个模型，如果孤立地看，并不具有真正意义上的有效性。模型的有效性只能通过它的客户程序来表现。P107

 

14、              有谁知道设计的使用者会做出什么样的合理假设呢？大多数这样的假设都很难预测。事实上，如果试图去预测所有这些假设，我们所得到的系统很可能会充满不必要的复杂性的臭味。因此，像所有其他原则一样，通常最好的方法是只预测那些最明显的对于LSP的违反情况而推迟所有其他的预测，直到出现相关的脆弱性的臭味时，才去处理它们。P107

 

15、              术语“IS-A”的含意过于宽泛以至于不能作为子类型的定义。子类型的正确定义是“可替换性的”，这里的可替换性可以通过显示或隐式的契约来定义。P115