《通过重构实现模式》读书笔记

《通过重构实现模式》读书笔记

作者: Joshua Kerievsky

1.  模式是面向对象设计的基石，而测试为先的程序设计和毫不留情的重构又是渐进式设计的基石。
    为了避免过度设计或者设计不充分，应该权衡使用这些编程实践，并按照需要不断发展变化。

2.  随着设计技术的提高，我发现自己使用模式的方式渐渐不同了：我开始“通过重构实现模式(refactoring to patterns)”，而不是在预先(up-front)设计中使用模式，也不再过早地在代码中使用模式。这种使用模式的新方式来自我运用极限编程(XP)设计实践的经验，它帮助我既避免过度设计，又不至于设计不充分。

3.  所谓“过度设计(over-engineering)”，指的就是代码的灵活性和复杂性超出了需要的水平。
    有些人之所以这样做，是因为他们相信自己了解到了系统未来的需求。他们推断，最好今天就把方案设计得更灵活、更复杂，它就更能适应明天的需求。这听上去挺合理的，但是有一个前提：你需要能够未卜先知。

4.  为了避免这一问题，人们决定分头负责系统的不同区域。这看似能使工作更容易，但是副作用又出来了：各人都在自己的小天地里工作，很少看看别处的代码是不是已经完成了自己需要的功能，最后产生出的是包含大量重复的代码。

5.  过度设计总是悄悄发生的：许多架构师和程序员在过度设计时甚至自己都没有意识到。而当公司发现团队的生产力下降时，又很少会有人知道是过度设计在作怪。
    程序员之所以会过度设计，主要的原因也许是他们不想受不良设计的羁绊。不良的设计可能深深地融入代码之中，对其进行改进不啻于严峻的挑战。

6.  我最初开始学习模式时，它们代表的是我很想精通的一种灵活、精妙甚至有些优雅的面向对象设计方式。完整地学习了模式后，我用它们来改进以前已经开发的系统，用它们构思将要开发的系统。其效果非常诱人，我认为自己走上了一条正确的道路。
    然而，随着时间的推移，模式的强大使我开始对更简单的代码编写方式视而不见。一旦什么地方我知道有两三种不同的计算方法，我会很快想到实现Strategy模式，而事实上使用简单的条件表达式就完全足够了。
    模式不是万灵药，不能过多地考虑模式，应该重新把精力放到简短、简单和直接了当的代码上。

7.  测试为先的程序设计能够高效地使可以工作的代码不断演变，其方式是将编程变成Kent Beck比喻的“苏格拉底式的对话”：编写测试代码就好像是向系统提问题，编写系统代码是为了回答问题，这样的对话不断反复，最后生成的就是我们所需要的系统了。
    测试为先的程序设计使我们能够首先让原始功能正确地工作起来，然后再不断改进，达到另一个必须的复杂层次。

8.  毫不留情的重构是这种渐进式设计过程中不可分割的组成部分。重构是“一种保持行为的转换”，或者按照Martin Flower的定义，是“在不改变代码可见(observable)行为的前提下，对软件内部结构的一种修改，能够使其更易理解，并降低修改的成本”。
    毫不留情的重构类似于对话中苏格拉底采取的方式，他通过抽丝剥茧、条析缕分、巩固概念，不断诱导对话的参与者改进他们对问题的回答。重构的特点在于，我们不能事先规划好什么时候应该改进设计了，应该在需要的任何时候进行。

9.  《Rafactoring》一书中，已经有一些通过重构实现模式的例子了：
    Form Template Method (塑造模板函数)
    Introduce Null Object (引入Null对象)
    Replace Constructor with Factory Method (以工厂函数取代构造函数)
    Replace Type Code with State/Strategy (以State/Strategy取代类型代码)
    Duplicate Observed Data (复制被监视数据)

10. 通过重构实现模式要注意理解“模式的意图”以及“重构的动机”。