读书「重构」

设计一个「类」的时候有什么原则

• 终极目标：提升代码的可理解性。
• 一个类应该是一个清楚的抽象，处理一些明确的责任。
• 封装，每个对象应该尽可能少了解系统的其他部分。这样一旦发生变化，需要了解这一变化的对象就会比较少。
• 修改函数和查询函数分开设计，在查询函数里不要做任何修改，同时最好用 get 和 set 命名。

重构的基本原则？

1. 添加新功能，和重构不可同时进行，重构时不加新功能，加新功能时不重构。
2. 重构时不应该添加任何测试。
3. 小步前进，频繁测试。
4. 一个函数应该且只应该完成一件事情。

对一个对象/函数来说，哪些地方很可能需要重构？

1. 拥有太多实例变量
2. 有超过百行的函数
3. 函数的参数超过三个
4. 牵一发动全身，如果经常一个改动需要在许多不同的类内做出小修改。
5. 如果有些数据项经常会成群地出现在一起，很可能需要拥有他们自己的对象。判断方法是删掉这些数据项中的一项，如果其他的数据立刻变得没有意义，那么说明他们应该在一起。

重构的方法有哪些？

1. 分解函数

   • 当看到一个过长的函数或者一段需要注释才能让人理解用途的代码，把这段代码放到一个独立函数里面去
   • 函数命名应该以「做什么」而不是「怎么做」来命名。

2. 用对象取代函数

   • 如果有一个大型函数，其中对局部变量的使用使你无法使用Extract Method，考虑把这个函数放进一个单独的对象中。然后再分解函数。

3. 移动类字段

   • 如果一个 A 类里的一个字段与 B 对象有更多的交流：经常被后者调用，考虑把 A 中的这个字段放到 B 里。

4. 移动类函数

   • 与移动类字段相似：如果一个 A 类里的一个函数与 B 对象有更多的交流：或者调用后者，或者被后者调用，考虑把 A 中的这个函数放到 B 里。但优先考虑移动类字段。

5. 分解类

   • 如果类的责任过于复杂，考虑分解这个类，抽象出一个新类。
   • 一个方法是思考如果把这个函数或者变量去掉之后，是不是其他的函数或变量就没有意义了？
   • 另一个方式是某些特性需要用一种方式子类化，而另一些特性需要用另一种方式子类化，那就意味着这个类需要分解。

6. 隐藏委托（Delegate）

   • 如果某个 Client 必须通过对象 A 的某个字段获得另一个对象 B，然后调用 B 的函数，那么 Client 就必须知道这一层委托关系，如果这一层委托关系发生变化，就不得不通知 Client，可以在把在 A 中放置一个简单的委托函数，将委托关系隐藏起来，去掉这一层依赖。
   • 当 Client 调用 B 的所有函数都被 A 承包了，Client 也就不需要知道 B 对象了。
   • 隐藏委托也是一把双刃剑，会使委托类 A 非常臃肿，这时候直接调用 B 反而可能更好，掌握合适的隐藏委托程度。

7. 外加函数

   • 尽量不要重载原始类函数，如果需要增加新功能，可以继承原始类，增加新函数。

8. 公开的字段自封装

   • 用 get 和 set 获取值。Python 并没有 Public 关键词，因此 Python类的所有属性都是可以直接访问的，应用这个设计理念，最好把 Python 类的所有字段统一在开头加上_以示私有变量，公开的变量用 @property 装饰器包装。
   • 如果字段是一个集合（list，set, dict等），谨慎对待 set 函数，需要的话，用 add，remove 会比 set 要更好。

9. 简化条件表达式

   • 尽管一个函数最好只有一个出口，但为了这一个出口的设计而加上多重 if else 判断并不一定划算。
   • 多重 if else 用来处理异常或者说处理完了已经对函数后半部分没有兴趣的话，可以直接 return 或者抛出异常。
   • switch case 的情况下，使用「多态」设计模式，将条件表达式的每一个分支放进一个子类内的函数实现，然后将原始函数声明为抽象函数。

10. 使用断言

    • 某些代码只有在某个条件为真的时候才能正常运行，此时与其用注释，不如使用断言来标明。
    • 不要滥用断言，只用它来检查「一定必须为真」的条件。
    • 如果断言的约束条件不满足的情况下，程序依然可以正常运行，考虑拿掉断言。

参考

Martin Fowler 重构——改善既有代码的设计