漫谈重构 其二

未分类

Feature Envy

所谓面向对象的中心思想就是, 把数据和对数据的操作封装在一起。但有的时候在编码过程中会出现这样一种情况，某类中某个函数对另外一个类中的数据有着过高的依赖，很多时候我们会看到某个函数在计算某个值时，会从另外一个对象中获取大量的数据，这个时候我们就认为其对外的怀有过分的 ‘依恋情结’ 。处理方法依情况而定大多数时候都是很简单的，把这个函数移动到它该去的地方就好了。
那么有时候这个函数对多个类都有 ‘依恋情结’ ，原则上： 判断哪个类拥有最多被此函数使用的数据，然后就让此函数与它最爱的那些数据在一起吧。其实中心思想就是总是将一起变化的东西放到一起。

Temporary Field

这一条真的是太太太太常遇到了，在coding时一不小心就会出现这种情况： 某个实例变量仅仅为某种特定情况而设。这样在代码被阅读时，常常会令人难以理解。在变量未被使用的情况下猜测当初其设置的目的真的是一件令人挠墙的事情。比如在实现一个算法时，由于需要传递一大串参数参与计算，但是又不想在看到这么恶心的传参，那么就不假思索的把这些参数全部扔到attr中，但是这些字段只在使用该算法时有效，这就会给阅读带来很大的迷惑性。

Middle Man

在我们把数据和操作封装成对象时，就伴随着委托的使用。当委托被过度使用时，也许就会有这样一个接口，它有一半以上的函数都委托给其他类。这时就应该直接和真正负责的对象打交道，如果这样不干实事的函数只有少数几个，把它们放到调用端。

Comments

读到这里时，我真正理解到了代码洁癖的存在。同时我也觉得书中提到的思想很有道理，就比如当你在项目中看到一段代码有着长长的注释，很多情况下都是因为这段代码结构很糟糕，难以理解。书中的思想表示：如果你需要注释来解释一块代码，那么就把需要解释的部分提取出来封成函数，起一个贴切易理解的名字来解释其行为（起名字真是永远的痛啊）。“当你感觉需要撰写注释，请先尝试重构，试着让所有注释都变得多余”。

其实重构过程中，测试的重要性已经无与伦比，没有测试覆盖下的重构真是令人心惊胆战并且抓狂烦躁。下次有机会会更新一篇关于构筑测试体系的理解。