第一部分：重构
　　第二部分：设计原则与代码所有权
　　第三部分：进化型设计
　　第四部分：灵活性与复杂性
　　第五部分：测试驱动开发
　　第六部分：性能与过程调优

　　第二部分：设计原则与代码所有权

　　在连载的第二部分，福勒讨论了一些设计原则，包括如何避免重复，如何分离业务逻辑和其表示，显式表达代码。除此之外，还阐述了重构如何依赖于代码所有权。

　　不要重复自己

　　比尔：你曾在书中提到：“代码应该实现任何逻辑一次且仅一次，这是良好设计的要素”。为什么你会认为这是良好设计所必不可缺的要素呢？

　　马丁：我曾经力图找到一种简单而通用的标准来区分设计的好与坏。 我想，避免重复是最有价值的准则之一。“一次且仅一次”是极限编程的座右铭。《程序员修炼之道》（The Pragmatic Programmer）的作者把其概括为“不要重复自己”（don't repeat yourself），也即DRY原则。

　　说到避免重复的方法，你可以来做这样一个练习。首先，走查程序代码，检查是否存在重复代码。然后，不需要考虑代码到底要完成什么任务，而 只需要坚定地移除这些重复的代码。反复进行这个过程。通过简单的移除重复代码，我最终“偶得”一个美妙而优雅的模式。这样的情况时常发生。所以我认为，好 的设计通常就是在消除重复代码后得到的。

　　比尔：你说过，你一直在试图将良好设计的一些基本原则罗列出来。除了“一次且仅一次”或称之为DRY原则外，还有其他的原则吗？

　　马丁：我想，另一个相当重要的原则就是分离逻辑层和表示层，或者说将用户接口（UI）和应用程序完成的实际任务相分离。通过采用这样的原则，我在面对变化时游刃有余。所以，我认为这也是一个可以依赖的良好设计原则。

　　比尔：你说你在面对变化时游刃有余，是不是说在将来对程序代码做改动会很容易？

　　马丁：由于表示层和业务逻辑相互独立，在程序维护阶段所需要做出的变化将变得相当容易。分离了表示层和业务逻辑的程序也很容易被测试。这个原则对我非常有用，我认为可以把它看作是一个很好的基本设计原则。

　　代码清晰化表达

　　马丁：最近，代码明确表达思想这一设计原则留给我很深刻的印象。这个原则的意思就是让代码很明确的表达出将要实现的思想。

　　比尔：你的意思是什么？能更“明确”的解释一下吗？

　　马丁：举个例子来说吧。假设你需要传递一些数据。你是把数据放在字典里，然后将数据从字典里传递出去呢？还是先构造一个类来容纳这些数据，然后将保存了数据的这个类对象传递出去？

　　或许你认为采用字典的方案比较好。因为不需要实现一个新类。而且使用该方法的话，当要改变将要传送的数据，也不需要改动字典类中任何代 码。另外，对于能把什么样的数据放到字典里，也是相当灵活的。比如说当需要往字典中存入新数据时，不需要改动任何代码，而只需要将数据以新的关键字放入字 典中即可。

　　但问题是字典很不明确。你根本就无法得知字典里关键字的真实意思。字典不能确定称买东西的人是顾客还是客户？即使是拼写错误也无法检查出 来。更重要的是，即使你看完代码还是不能回答这样的问题：“访问这些数据的接口是什么？通过这些数据我能得到什么？”所以说，字典是很不明确的。而使用类 的话——即使你不得不重写所有成员变量及其访问函数——一切就变得明确起来。这时只需要查看源代码就知道这些数据是什么了。

　　比尔：我同意明确性能让我们更容易理解代码。

　　马丁：是的。我大概在去年或前年做 IEEE 软件专栏时，就曾经关注过这些简单的原则。在一篇标题为“要明确化”（To Be Explicit）的文章中还举了几个例子来阐述明确性。

　　良好设计的目的

　　比尔：你还提到过，“我强烈的认为良好设计是软件快速开发的一个基本要素。事实上，所有良好设计的目的就是为了允许进行快速开发”。

　　马丁：是的。

　　比尔：你好像前面提到过这点，能为我们解释一下为什么吗？听起来似乎你认为良好设计的唯一目的就是提高开发速度。

　　马丁：是的。我认为从多方面讲都是这样的。明确性能帮助我们阅读代码，还能帮我们快速应对需求变化。此外，代码设计得好的话，就很容易找到漏洞所在，很多漏洞将不再有藏身之所。