《重构》第一章 笔记

《重构》第一章：Refactoring, a First Example

书中描述的我比较认同的观点：
1.如果你发现自己需要为程序添加一个特性，而代码结构使你无法很方便地那么做，那就先重构那个程序，使特性的添加比较容易进行，然后再添加特性。

2.每当我要进行重构的时候，第一个步骤永远相同：我得为即将修改的代码建立一组可靠的测试环境。

3.提炼一个函数时，我必须知道可能出什么错。

4.段代码里头找出函数内的局部变量（local variables）和参数（parameters），
不会被修改的变量都可以被我当成参数传入新的函数，
如果只有一个变量会被修改，我可以把它当作返回值。

5.重构步骤的本质：由于每次修改的幅度都很小，所以任何错误都很容易发现。

6.代码应该表现自己的目的

7.函数应该放在它所使用的数据的所属object（或说class）内

8.在另一个对象的属性（attribute）基础上运用switch语句，并不是什么好主意。如果不得不使用，也应该在对象自己的数据上使用，而不是在别人的数据上使用。

9.为什么我选择「将租期长度传给Movie对象」而不是「将影片类型传给Rental 对象」呢？因为本系统可能发生的变化是加入新影片类型，这种变化带有不稳定倾向。如果影片类型有所变化，我希望掀起最小的涟漪，所以我选择在Movie对象内计算费用。

我从书中得到的启示：
1.评价一个面向对象程序设计得好不好，是否符合面向对象精神，一个很重要的标准就是：它在应对可能发生的需求变化的情况，是否能很方便的修改。
因此程序设计得好坏不是绝对的，与当前的需求情况，以及有可能发生的需求变化趋势有关。

2.如果要重构的代码是一片混乱，不知如何入手。可以先不考虑设计的问题，而是每次找出一个最令人不爽或者最容易修改的地方，一个一个地攻破。

3.怎样判断一个操作属于哪个类？
a.如果操作只和某一个类的成员有关，那么操作属于这个类
b.如果操作和几个类的成员都有关，那么判断哪个类更有可能发生变化，就属于哪个类

4.在例子中，原来的设计是电影作为基类，然后三种电影类型继承电影基类。
但是这样有个问题，某类型的电影在它的生命周期类不能改变自己的类型。
因此改为将电影的收费方式作为基类，派生出三种具体的收费方式，而收费方式作为电影的一个成员。
这种改法，是“封装变化”的一个体现。

书中描述的我不太认同的观点：
1.临时变量往往形成问题，它们会导致大量参数被传来传去，而其实完全没有这种必要。
说明：这句话我并不反对。但是作者似乎对临时变量特别反感。
在例子中，作者这么执著地消除临时变量，甚至愿意牺牲性能或者导致代码重复。
我认为其中有些临时变量是不必要消除的。

2.重构时你不必担心这些，优化时你才需要担心它们，但那时候你已处于一个比较有利的位置，有更多选择可以完成有效优化。
说明：这句话是关于性能的。我也不反对，但也不像作者那样绝对。
在例子中，作者将一个while循环封装成一个函数，然后反复调用这个函数。
我认为，如果函数里不是while语句，那么重复调用还可以的。
虽然现在还不到优化的时间，但明知道有性能影响，还要去写，我也接受不了。
就好像，还不到改bug的时间，所以明知道这么写有bug，还是要去写，一定要到改bug的时间再去解决这个bug。

转载于:https://my.oschina.net/windmissing/blog/690384