《重构》读书笔记7（第七章完结）

前几章以后补上

7.1封装记录

把记录封装成类。
比如一条用json格式存储的记录，是一些字段名和其对应的值：
{"name": "xxx", "country": "GB"}
可能还有嵌套。（暂略）

为什么要封装成类呢？用记录不挺简单的吗？自己写的时候是简单，等过两个礼拜再来看就不是这么回事儿了，如果是debug看别人代码就更想当场去世了，不知道里面究竟有哪些字段，不知道在哪里用了、哪里修改了，总之是一片混乱。写的时候简单未必一定是好事，维护也要较为方便才行。

记录变成类以后就很清晰，写操作和读操作都可控了，所有调用点都能通过文本搜索或者IDE找到，类的定义处就可以看到所有字段和它们之间的关系，想给某个字段改名也比之前更不容易漏改。

读操作有不同的实现方法，各有优劣。一种是像写操作一样提供API，但代码量就上去了；可以返回原始数据的副本，但复制可能导致性能问题；还有一种方法，封装集合（7.2），但也会增加代码量，不过可以提供更细的控制。具体要采取什么做法还是要看具体使用情景并权衡利弊。

7.2封装集合

这个集合应该就是指像数组、列表这种数据结构（可能有序也可能无序），封装集合就是指提供更新一条数据的方法（增加或删除列表中的一个条目），相比一次set一个数组而言，这个控制比较细。
好处就是更新点清晰，debug的时候很方便。缺点是增加了代码量，而且实际应用时未必需要这么细的更新，有时候封装记录（7.1）就够用了，所以看情况使用。

7.3以对象取代基本类型

本来是个基本类型，比如数字或者字符串这种的，但随着开发与这个数据项相关的操作越来越多越来越复杂，比如进行比较，那么可以把这个数据项封装成类，并把这些操作封装成类的方法。

7.4以查询取代临时变量

就是把临时变量的计算封装成函数，用的时候直接调这个函数就行了，这样代码会干净很多，不用面临一堆临时变量，尤其是给封装的函数取个好名字的情况下。而且把计算临时变量抽离出来成为函数，既方便以后检查计算是否有问题（没有和调用它的逻辑混在一起），也方便复用。

坏处也有一些，比如这个临时变量在调用处被重复使用多次，如果封装成函数每次都去调用函数可能会造成性能问题，但作者的观点是先重构出容易理解和迭代的清晰的代码出来，再去解决性能问题，当然也可以选择抽出函数但保留临时变量。

7.5提炼类

在开发迭代中，随着一个类越来越大、功能越来越多，其中可能会有一些数据及其操作（函数）可以抽离到一个新的类中。
注意：搬移函数时先搬底层函数（被调比较多的）。

7.6内联类

这是提炼类的反操作。
当一个类不再承担足够责任就可以把它干掉了，干掉的方法就是把数据和操作搬到一个联系比较密切的类。

7.7隐藏委托关系

「一个好的模块化的设计，“封装”即使不是其最关键的特征，也是最关键的特征之一。“封装”意味着每个模块都应该尽可能少了解系统的其他部分。如此一来，一旦发生变化，需要了解这一变化的模块就会比较少——这会使变化比较容易进行。」
尽量不要让调用者越层调用，知道的中间细节越多，以后改代码越困难，把细节都封装到提供者的函数里去。

7.8移除中间人

是隐藏委托关系的反操作。
当调用者使用了越来越多的被隐藏的对象的功能时，中间类就要添加越来越多的委托函数来转发，这时就可以考虑把中间人干掉，去除这些委托来委托去的函数，改为直接调用。

7.9替换算法

这个比较好理解，如果一个问题有了更好的方法，那么就会用它替换掉之前的算法，所以要确保之前的算法已经干净地被抽出到一个函数中、并且有可靠的测试。

-FIN-第七章