《重构——改善既有代码的设计》读书笔记（五）

一、明确一个对象的作用

1.不同类之间函数的耦合

一个类A的某个函数在另一个类B中常被调用而自己几乎不用，那么这个函数就该被转移到另一个类B中；或是将类似的功能代码转移到另一个类B中，只是将A上的原本调用这些代码的函数改为一个委托函数。这种情况我在实际中遇到的多是在某个类中声明了一个静态函数，然而这个类本身对这个静态函数可能不用或是用的很少，只不过这个类的作者在写这个类的时候顺手加在了这个类中。其实对于这种函数，应该建立一个单独的文件来专门存放这些函数，或是在一个模块中某些功能会被到处调用，那么他就应该被单独列出来而不是混在某个类中。同理，一些常量以及宏定义也应该如此处理。

2.filed的放置

这个问题是说一个类中的某个字段被另一个类多次用到，作者建议将这个字段搬移过去。但是我觉得好像这样做似乎太过关注代码的简洁而没有考虑逻辑，例如我有一个界面显示类ADialog,这个类上有一个变量int nParamNum，这个变量的值会被显示在界面上，然后同时对于这个界面我们还有一个管理类AManager,这个管理类主要是对ADilaog上的数据进行处理然后将处理后的值返回给ADilaog进行显示。那么这时，这个nParamNum在ADialog上或许只用到了三次：①被赋值  ②传递给AManager ③将nParamNum显示出来；而nParamNum在AManager中可能会有多个函数调用其来处理，那么这种情况nParamNum就应该被转移到AManager上去吗？我觉得还是不应该的，我认为nParamNum还是应该放在ADialog上而同时在AManager也有一个存储nParamNum值的变量，而不应该直接将nParamNum在ADialog中删除。当然作者也没有绝对的说遇到这种情况就要完全按他建议的做，实际问题还是需要考虑实际情况的。

3.精炼类

一个类应该是一个清楚的抽象，处理一些明确的责任。实际工作中，可能在一个类最初被创建时是这样的，但是随着需求的更改功能的增加后来者的维护等等原因，一个类上可能就会多了很多与最初设计这个类的初衷不符的代码，而将这些问题处理掉就是重构的意义。一个类要有一个明确而独立的功能，之前说过在一个类中不怕小函数多，同样在一个工程项目中也不怕类多，为了代码的清晰与便于维护哪怕为一个函数建立一个类都是值得的（当然，真的为一个函数建立一个类确实有些浪费，所以可以和上面说的一样，在一个模块中单独建立一个文件将一些以单独函数的形式存在的功能放在这个文件中作为静态函数，这样也比把这些函数混在类中更易于维护）。另外还有对于类的私有化是非常重要的，两个类之间耦合太严重很多情况下都是私有化做得不够完善，在C++中，可能在一个类中建立了一个另一个类的对象，然后就是一堆的“.”或是“->”就把要处理的值都取了过来，这种行为是很不好的。如果在一个类中用到了很多对另一个类的“.”或是“->”那么你就该考虑另一个类的私有化问题，以及这些“.”或是“->”相关的功能是否能在另一个类中封为接口了。

4.清除多余的类

多余的类是指其功能与另一个类或是另一个类的某段代码极为相似时，应考虑删除这个类或是与其相似的功能的代码，或是考虑将与其相似的类抽象出一个父类，然后在父类的基础上再拓展出原功能。

5.隐藏委托关系

这种情况就是我为了保护程序的封装性，例如上图中的例子：假设client代表客户类，person代表销售者类，department是销售者所属的部门，在最开始时（图的左侧），如果客户想要知道一个销售者的部门经理，那么客户就要找到销售者person的所属部门department，再根据部门找到其部门经理。但实际上作为客户并不需要了解销售者的部门结构，而应该由销售者直接告诉客户他的部门经理是谁，那么就在person类上添加一个接口，调用自己所用的department类来取到部门经理再返回给客户。这样客户就不在能了解到销售者的部门相关，而是直接与销售者交流就足够了。

6.去除中间人

这个与上一个刚好相对。上一种情况是客户在与销售者交流的情况下想要知道销售者的部门经理，而客户主要的动作还是与销售者交流。但是到了现在，可能客户有了更大的需求，销售者已经权限不够没法做主了，那么按照上一次的做法客户每次想要与销售者更高层次的交流都需要通过销售者来转达，那么这也是没有必要的，直接让客户去找销售部门经理就好了。这种情况就是中间人委托过度。

这种问题遇上一个问题的区别主要在于客户与谁交流的更多，如果销售者足矣应付这个小客户，只是客户偶尔提到销售部门，那么就是用隐藏委托关系的模式更适合，而如果是个大客户，足够与整个销售部门或销售部门的领导者对话，那么就去掉中间人。作者也提到了，中间人的委托度很难定好，只有根据实际情况不断调整代码结构才能让代码一直都清晰明了。