本文作者介绍：Michael Feathers是Object Mentor International公司的技术顾问。他的工作不仅是技术开发，他还参与对世界各地技术团队进行培训、指导等工作。他曾开发了将JUnit迁移到 C++的CppUnit的初始部分，还有FitCpp——一个C++版的FIT基础测试框架。他是《Working Effectively with Legacy Code》一书的作者。
Michael Feathers
重构的方式千差万别。当在分析一个很大的方法时，我会首先看一下它的整体结构，心里对如何分解它有了一个初步的感觉。里面的条件判断代码块通常都会是我认为有问题、可以入手的地方。
|
1
2
3
|
if (...) { ...} |
当看到有一个像这样的if语句后，我知道我面临着选择。我可以 提取这个if语句以及和它相关的代码块到一个新方法里，或者我只提取相关代码块。我并不知道这样或那样做哪一种更好——这要根据上下文来判断。有时候这个 条件语句非常重要，有必要重点突出它，而另一些时候，这些if语句和它的代码块可以干净的提取出去，使得调用它的程序的显得更整洁干净。但是，我们如何调 用这个提取出去的方法呢？
让我来看看一个实际例子：
|
1
2
3
4
5
6
|
if (alarmEnabled) { Alarm alarm = new Alarm(); ... ... alarm.sound();} |
我们可以把整个if语句和它的代码块提取到一个叫做soundAlarm的方法里。
|
1
|
soundAlarm(); |
这样好吗？
大多数人最初的反应会说：现在的这块代码有时会说谎。它告诉我们它将要响起警报，但有时候它并不响。通常，如果有这样说谎的代码不是一件好事，所以，选择另外一种重构策略可能更好：
|
1
2
3
|
if (alarmEnabled) { soundAlarm();} |
但是，这样看起来并不像之前那样干净。
这 种两难抉择让我想起了Null对象模式。Null对象模式就是一种经常会让人感觉代码在说谎的另一个例子。在主调代码里，我们看到有消息发送到一个对象， 但让人震惊的是，我们发现相应的动作并没有发生。但并不是所有的人都会有这种感觉。我所在的这个团队里大量的使用了Null对象模式，我们对代码的理解有 这样的共识：当你告诉一个对象做X时，有时候它并不去做——发送执行X的消息意味着有时X事件并不一定会发生。这要由这个对象决定。
我的直觉告诉我，这没什么，但你需要理解为什么会这样，这是十分重要的——这是一个内部的理解问题。
如果说多态有任何意义，它至少在说对象是自己管理自己的。我们给它发送一个消息，这是由它来决定应该去做什么。这是面向对象的核心，也是 Alan Kay 最初的对对象的认识之一——消息只是它们的信息传递。这种观点在如今并不占主导地位。
当我非常想让这种提取变的更易懂时，我通常有两种策略——使用一种意指一个事件的名字，或泛化这个操作。在这种情况下，我会选择使用一个事件风格的过去式的名字。
|
1
|
intruderDetected();//入侵检测 |
这种事件风格的命名方式的好处是，它强调了事件条件，而不是动作。现在，我们可以将任何想要的东西都放到intruderDetected方法里。
我们还可以选择去泛化这个操作。相对于说我们要想起警报，我们可以换成说我们要向世界通知一个关于我们的状态的信息。
|
1
|
performNotifications();//执行通知 |
如果使用一个像performNotifications这样的名字，我就能使事情变得抽象。这里的通知是一个还是多个并不重要。关键是，主调程序触发这个动作，但不意味着动作没有发生就可以解释成在撒谎。
尽管这样，我仍然疑惑，我们是否应该永远不要相信一个显示它肯定将会做某事的方法名？
如果它没有做，我们可以认为它在撒谎吗？
和牛头聊了一下这个情形，例子：
if (save) { //save1... //save2... //save3... }
牛头说，这种情况下是不是把if一起提出去，要看业务，如果不提if语句，那么就很简单了，起个方法叫saveData,在if里调用，如果决定把if语句提出去，那么可以从起好名字来解决。方法名就叫做saveDataWhenNeedSave，这只是一个简单的方法，重要的是，什么时候决定if语句跟着提取走，什么时候不提取
我今天又想了一下，所谓看业务决定是不是要把if语句包含着提取走，主要还是看代码复用的情况，如果saveData还有别的调用，并且他们不需要根据save变量决定是否保存，那么这个if显然不需要带入