简单系统的条件

　　比尔：在《重构》一书中，你引用了 Kent Beck 给出的简单系统的四个条件：1）通过所有的测试；2）揭示所有的意图；3）没有重复代码；4）使用最少的类和方法。那么，对你来说，简单性是什么？

　　马丁：我想，很难给简单性一个定义。我很喜欢 Kent 的四个条件。第一条提醒我们必须要通过所有的测试。

　　比尔：但是，这与简单性有什么关系呢？我完全可以把事情搞得很复杂，也一样通过所有的测试。

　　马丁：这倒是没错。但是，一个设计良好的系统，首先必须是一个能运行的系统。如果你把这个约束去了，那……

　　比尔：噢，你是说，通过测试是必要条件但非充分条件。

　　马丁：没错。一旦测试通过，你接着就该问自己，是否所有的重复代码都被清除干净了？而另一个条件， 揭示所有的意图，则是非常难把握的一个条件，因为它太主观了。基本上说，你应该能够读懂代码，知道它在干什么。代码所包含的设计意图应该能够通过代码很明 显地体现出来。像是命名合理的方法就是一个简单的示例。与其把一个方法起名为 x74-3，然后通过注释来说明这个方法是干什么的，不如通过该方法的名字直接告诉人们它要做什么。这样更能起到揭示其意图的作用。问一下你自己，你的代 码结构、命名方式等等，是否揭示了代码的意图？

　　当上面提到的这些问题都解决了的时候，你显然还希望代码不要有多余的部分。注意，最小化所使用的类和方法一定是最后一步——在其他条件都满足之后。人们常常对于第二个和第三个条件的次序有不同看法。但通过所有的测试一定是第一位的，而最小化代码量则一定是最后一步。

　　设计接口

　　比尔：当我想到设计的时候，总是习惯性地从接口这个角度去考虑。而在有关模式和敏捷方法的一些书籍 中，包括“四人帮”的《设计模式》（Design Patterns），Kent Beck 的《解析极限编程》（Extreme Programming Explained），还有你的《重构》，往往都是把接口和实现作为一个整体的代码来讨论。那么，在设计中是否还有必要从接口这个角度去考虑？

　　马丁：我想，从接口这个角度去考虑是非常基本的。事实上，我认为“四人帮”的那本书比其它任何一本关于面向对象设计的书都更强调接口的作用。

　　比尔：为什么这么说？

　　马丁：其它关于面向对象设计的书也许会在某处这样说道：“啊，接口实在是太重要了。”而“四人帮” 的那本书，在前几章就开宗明义地指出，面向接口编程（program to an interface）到底意味着什么。而这本书后面的几乎每一个模式，都在说明接口是如何独立于实现而变化的，以及面向接口编程的好处。

　　我想，极限编程也是一样。测试优先设计（test-first design）—— Kent 称之为测试驱动开发（test-driven development）——的全部意义，或者说，最主要的驱动因素，就是接口。因为当你先编写测试的时候，你实际上所考虑的是接口。编写测试就是在设计 接口。当你先编写测试后实现代码的时候，你实际上是先定义清楚了接口，然后再实现接口。接下来你就可以编写一整套自动测试来描述接口是如何工作的。

　　比尔：我在读这些文献的时候未曾体会到这一层。我所领会的是，首先设计接口，接下来有时候会先写测试，有时候会后写测试，有时候则不写测试。

　　马丁：没关系的。

　　比尔：既然先写测试与考虑如何设计接口是相关的，那么它们是否是一回事？

　　马丁：可以这么说。不过我想，对许多程序员来说，先写测试的说法会更具体形象些。构思接口是件困难 的事情。但是，当你坐在那里对自己说“我需要写一个测试，以使这一个小功能得以实现”的时候，你就要考虑，怎样写这个测试最好？而这时，你就在考虑接口。 这是一个潜移默化的过程——你的的确确是在构思接口，而且是以一种渐进的方式。你不会对自己说，“啊，我需要构造这个类，让我们来把这个类的所有接口都搞 清楚，然后再实现之吧！”相反，你会说，“嗯，这个类需要实现这么一小块功能。来为此写个测试吧！”在编写测试的时候，接口就随之浮现出来。