《重构》第一章 笔记
《重构》第一章：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。