零雨其蒙原创 转载请注明

1       测试驱动开发

测试驱动开发不是什么噱头，而是真正有用的开发实践。今天派给我一个任务，让我解决一下退休提醒功能的Bug，我没看出原来的代码有何错误，不过觉得设计思路不十分的好：将数据库中所有的员工都取出来，然后再筛选应该被提醒的员工。而我觉得应该直接到数据库中去做筛选，返回大量无用的数据是资源的巨大浪费（我们在甲方公司里面开发，其网络之差令人发指）。

正好，我在研究TDD（本文有时指的是测试驱动开发，有时指的是测试驱动设计，因为两者都是存在的），想想何不来一次彻底的实践，真正的、完整的来一次TDD，体味一下其中的乐趣。

由于我们的开发工具是Delphi，因此自动测试工具自然而然就要使用DUnit了。尽管有的人说TDD不一定非得用自动测试框架，我也在使用VB进行OO系统开发时，用自制的测试程序进行测试，不过觉得那样都有一种不爽的感觉。因为总需要去维护复杂的测试代码，不能全力投入到测试驱动设计中。

2       准备工作

首先介绍一下业务：

很简单，就是在一个界面上显示即将退休的人员，具体提前多少天显示是从数据库中读取的参数。

然后配置DUnit环境，网上有n多教程，然后安装了一个DUnit plug-in插件，方便开发，网上也有讲解。

将Stop on Delphi Exception前的对号取消，这样就不会在出现异常时跳出了。

3       开始TDD之旅

本文是我进行TDD的实践记录，当然其间的思考要比这个多一些，不过主体部分基本都包含了，而且绝对写实。本文不是TDD的颂歌，我也提出了自己在实践中遇到的困难和疑惑。希望能给读者带来启示。

创建工程文件HR.dpr，然后使用DUnit plug-in，New Project，就自动在HR.dpr所在文件夹建了一个dunit文件夹，新建的测试工程默认名为HRTests，这是很好的规范，默认即可。然后New TestModule，建立一个测试单元。

接下来的工作就是在这两个同时开着的工程中开始工作了，一会我会切换到HRTests编写测试用例，一会我会在HR下编写产品代码，然后再回到HRTests下运行Dunit，进行测试。

3.1 领域驱动设计

   首先构建领域层，领域概念就是退休（Retired），退休人员（EmployeeRetired）了。

   先创建这两个类，不少文章说先建立测试用例，然后测试时肯定显示红条，因为被测试的类还没有建立，我觉得没建立的话连编译都过不了，怎么运行DUnit啊？

   然后就可以开始根据想象编写测试用例了。思考对象的责任和工作方式，然后切换到产品工程添加这些责任。（有点像一边画顺序图一边画类图进行责任分配） 

首先，我创建类TRetire

给TRetire类分配一个责任：查找退休提醒参数：

   这是一个空壳，没有实际的内容，然后切换到HRTest工程，会出现下面的对话框。

   在HR工程做了任何改动，保存后，都会在HRTest中有提醒。

   可能很多人从来没见过测试用例长什么样子，下面就给出一个完整的例子。

在编写测试用例时，我发现返回的不是一个一维的表，而是二维的，我还是使用了对象来报存另一维的数据，又创建了一个名为TRetirePara的类。其属性如上面的代码所示。

然后编译运行HRTest，出现DUnit，点击绿色的RUN按钮，出现红条。错误是EAccessViolation。

   这是因为没有创建TObjectlist的实例paraList，而在testGetretireAwokeParaList中访问了它，这时切换到HR工程，在getretireAwokeParaList中添加如下代码。

   再次测试。

依然显示红色，错误是List index out of bounds，这是因为在getretireAwokeParaList方法中并没有向paraList中添加任何对象，这时需要再对getretireAwokeParaList进行重构。

3.2 步伐到底要多小？

当有了“测试驱动依赖症”后，就想让DUnit帮我思考一些内容，比如下一步应该编写什么。通过测试，我不断的清楚了自己下一步的任务。但是或许不需要如此小步的前进，如果已经有了很好的思路，可以一下子把刚才的程序都编完，甚至把整个getretireAwokeParaList方法都完成。

然而由于没有太多的plan，想一点编一点的，难免就会采取这样小的步伐，其实这样也很好，因为不至于写了一大堆，错了都不知道哪一句是罪魁祸首。经常看到有人在面对一堆不知道在哪个地方出错的代码时，采用了删除所有，然后一句一句还原，发现到哪句错误就改哪句。这种做法一般都被用于没有调试器的环境，比如HTML页面。如果有了调试器，传统的做法当然是设置断点，然后利用调试器进行跟踪。关掉调试器，以测试代替调试的一个支撑点是，不大可能会出现大段的需要你去跟踪错误的代码，因为很小的一步重构进行之后，就开始测试了，哪里有错误一目了然。当然调试器的作用并不只是跟踪某个变量在运行时的值的变化，还有理解代码在汇编一级上是如何工作的，这将更加有利于你调错。但是，总而言之，调试器肯定是帮助你调试错误的，小步前进的单元测试可以帮助你在不使用调试器的情况下，找出错误。

3.3 混入持久层的测试

或许看到这篇文章的您，有更好的方法来完成这样的测试，请您告诉我，因为我也是使用Dunit进行TDD的新手，希望分享您的宝贵经验。

我们使用的是ODAC控件连接ORACLE数据库。在产品代码（HR.dpr）中，通常我们都是直接加载数据模块中TOraSession，来连接数据库，再用TOraQuery与之相连。getretireAwokeParaList的主要操作是从数据库中获取记录，产品代码如下：

   这比你在上一节看到的代码又丰富了许多。_qry是用到的TOraQuery类型的变量，它接受TOraQuery实例。由于进行单元测试时，HR.dpr是不启动的，因此DM根本就不会被创建。

   考虑再三，我在测试项目HRTest.dpr中加入了数据库连接代码，并将创建的TOraQuery实例赋值给TRetire的属性（property）qry。代码如下：

起初，我创建了TOraSession对象，可是不知道为什么说驱动器有错误，于是就创建了一个DM（数据模块），然后获得其中的HRSession。注释掉的代码有何错误还请高人指点。之后我又写了个测试连接是否成功的方法。

   之后再进行测试，绿条终于出现了！

我在之前还犯了错误，总是出现红条。后来才发现原来对象创建没搞清楚。这个错误在我编写Java程序时也犯过，看来一定要注意阿。

原来将retirePara:=TRetirePara.Create;这句写在循环之外了，结果测试时，只有最后一条（paraList.Item[3]对应的结果）是正确的。这个错误大家一看就知道了，每循环一次都需要创建一个retirePara对象，要不然向paraList添加的其实都是一个对象，而paraList的每个元素都是指向同一个对象引用，赋值之后，当然每个对象的属性值都是一样的啦。

还有，在测试用例中进行比较时，我刚开始图省事，都使用check，结果错了后没有任何提示，后来到TestFramework中查到了CheckEquals方法，这个方法很好，如果出错了，会告诉你期望值是什么，实际值是什么。

3.4 进化式设计

TDD韵律操是：编写单元测试——〉测试，红条——〉编写产品代码——〉绿条——〉编写单元测试——〉测试，红条——〉编写产品代码——〉绿条，编写产品代码并不能总是一气呵成，因此就会在编写部分产品代码——〉绿条——〉重构——〉测试，绿条/红条——〉重构——〉测试，绿条/红条

    下面开始编写function retireAwoke(qry:TOraQuery):TObjectList;方法。还是先写测试用例。   

     这里面有个问题，这个方法的作用是查询并返回所有的符合退休条件的员工，每天的人可能都不一样，那么该怎样写测试用例呢？这个或许应该从DUnit的测试装备中读取（如果DUnit有的话，我也不知道有没有），也可以从一个文本文件或者Excel中读取，这样或许好些。但是这依然不是一个可回归测试。

最终想的办法是通过SQL语句先查询一下，看看有哪些记录，而且这个SQL语句与程序中的不尽相同。主要是将计算退休者生日的程序写在了SQL中还是写在程序中的区别。

使用如下的SQL语句进行查询：

用于返回60岁退休的男性管理人员（提前90天提醒）。以下是SQL Plus的查询结果。

还需要说明的是，有四种情况需要测试，但是为了快速实现，我只是写了其中一种情况，即男，管理人员。然后我就写了测试程序。

产品代码只是读出了参数列表的第一种情况。然后嵌套进SQL语句中进行查询。

很高兴，测试通过了！不过实话实说，也并非一次就能做成功的，其中SQL语句写错了，就查了半天，DUnit报错说missing expression。我就是一个这样马虎的人，很难把程序一下子写对，有DUnit做保证，小步前进，以免陷入绝境，在Bug丛生的密林中寻找，当是非常痛苦的事情了。

3.5 重构

对于XP，我觉得简单设计、TDD、重构、持续集成、小规模发布是连在一起的实践。简单设计而没有重构，就变成了Code and Fix。只有重构，而没有单元测试的保证，无异于徒手穿越原始森林，没有安全保证。单元测试，继而持续集成、小规模发布，才能实现工作的软件。再加之结对编程，以提高代码质量；完全客户现场，以捕获最真实的需求和得到最真实的反馈，以最快速最真实的态度响应变化；集体代码所有制，以减少人员流动的风险，和提高复用；40小时工作日，以避免累死和创建更优质的代码。这是我体会到的XP实践的好处，随着实践和思考的增多，我觉得自己越来越认同XP的观点了。

闲言少叙，继续编程。继续完成其余三种情况，目前而言，就只有四种类型的员工。

 |      管理人员  |      工人

男|                               |

女|                               |

从注释（//满足条件的男管理人员）开始，下面每一类型都要重复一次代码，当然，可以直接在其中写循环语句，但是看到Too Long Method恐惧症，大量的查询代码混在这个方法，让我觉得很别扭，于是我觉得将它们重构出来，采用Extract Method。

首先新建getretireAwokeList方法，将从数据库中取出需要被提醒的退休人员的代码Extract到其中。然后整理局部变量。

不断的编译，来帮助我检查错误，是不是某些局部变量没有迁移过来，有没有变量重名等。经过一番折腾，编译通过，运行测试。

进行测试，悲剧发生了，在显示绿条后死机了，我想可能是内存释放有问题了。

结果果然如此，下面这段程序结束后没有释放employeeRetiredList。

释放了employeeRetiredList之后，其中的所有对象也就跟着被释放了。

3.6 整合UI

最后一步，设计一个展示被提醒的退休人员信息的Form，然后放置一个叫做sgdRetire的StringGrid，这时就是通过列表循环赋值到StringGird中就可以了。

但是一定要注意：对象的释放问题，对象生命周期的开始到完结，一定要好好想清楚。不知道那些痴迷与C/C++的开发者，是如何处理内存释放问题的，我的Delphi面向对象编程经验还不算多，对我而言，仔细分析每个对象内存是否被释放了，真的是一件非常痛苦的事情。所以还是比较喜欢Java那样带垃圾回收器的语言。但是通过创建和释放对象，来理解对象的生命周期意义，对于理解对象还是很有帮助的。

4       真的要选择TDD吗？

仔细的设计测试用例，不仅是在思考对象具有哪些责任，同时也是在思考对象如何使用。先总结一下使用TDD的几点好处：

1.         可以不断地测试，以保证代码是正确的。而且在正在开发的这一段时间内，测试是可以不断进行的，期望的结果不会有什么大的变动。（时间长了就不好说了，比如本文给出的例子。）

2.         由于有了可以重复进行的测试保障，因此可以大胆的进行重构了。

3.         在编写产品代码之前考虑什么情况是正确的，而且可以编写代码边增加测试数据，这样可以有利于全面的测试。据说配合测试装置，还可以由业务人员填入测试数据，这样样本就更大了。

4.         因此结果是骗不了人的，当红条亮起时，你就知道是刚刚编写的那段代码错了。

5.         在编写测试用例时，就是在思考这个对象干什么的时候，这有利于养成针对接口编程的好习惯，同时这样也就自然的为对象分配了职责。

6.         在编写测试用例时，还需要考虑这个对象是如何使用的，这无疑就是在编写对象的使用说明书了。

7.         由于以上两点，可以使我们为了使对象或对象的方法便于测试，而降低了对象间的耦合，减少了依赖。

8.         进行测试驱动开发，还会使得我们倾向于领域驱动开发，而不是UI驱动或数据库驱动，同时这也有利于将各层解耦。

另外有以下几点值得思考：

1.         测试驱动开发提高总体效率的前提是什么？毫无疑问，从长远来看，测试驱动开发提高了代码质量，而软件的成本往往从维护阶段开始（譬如我们现在正在维护的这个项目，让人欲死欲活的）。但是，我在进行TDD实践时，确实比直接开发花费了更多时间，包括思考测试用例应该怎样写，比如测试持久层就想了半个多小时。

2.         另外，真的要关掉“异常时中断”功能吗？有几次总是报ORA***:missing expression错误，我真的想设个断点看看到底SQL语句成什么样了。虽然错误的发生就在那两三行中，或许某一个不超过20行的函数中，但是我还是花费了很多时间去反复测试，仔细看代码，观察到底在哪错了，因为DUnit不会告诉你是哪行错了。（或许有告诉，我不知道在哪而已）

3.         不知道为什么，我是将产品代码所在的文件夹放在了search path中了，可是总会遇到产品代码更新了，测试代码那边读到的还不是最新结果。刚开始，我写到会出现那个代码已更改的提醒，之后代码就同步了，可是后来重启了一次Delphi就不行了。

4.         就是内存释放问题，在测试代码中和产品代码中都要考虑内存释放问题，很烦。

虽然在进行TDD实践过程中，碰到了不少挫折，不过总体而言，我觉得驱动测试开发让我在编写测试用例时思考对象的工作方式，是一种渐进的思考过程。其实，我一直的编程习惯是，面对一个问题先花费一两天时间思考，把各种关系都搞清楚了，然后在两个小时内一气呵成，由于思考的很清楚，因此错误也挺少的。Planned Design和进化式设计两种方式都让我感到获益，XP之所以叫做极限编程，其中一个极限的部分可能就是其简单设计的极限，不需要任何的架构设计，就根据用户故事开始编程。不过我觉得我需要更多的实践TDD，那些编写测试用例遇到的困难，我想或许每个新手都会遇到，唯有多多实践才能真正的提高。

5       大项目的思考

在大项目和大的团队中推行TDD是有困难的。

1.         首先，TDD需要编写产品代码以外的测试代码，很多程序员为了快速完成任务（有些人的时间只够编写产品代码），不会愿意写测试代码的。虽然它从长远考虑会有很多好处，但是现在的程序员有多少会想很远呢（这也跟责任心有关）？可能等到维护时，我都走人了。

2.         其次，TDD需要开发人员有很强的设计能力，在这里我讨论OO设计，不过我发现，在中国，程序员对OO都知之甚少。更甭说进行优秀的OO设计了。况且，Delphi不支持垃圾回收，习惯于“拖拉机”方式的程序员估计要造成很多混乱了。

3.         最后，比如我们这样的大型项目，数百张数据表，上千个窗体，如何进行TDD，如果我自己没做过，真是很难说服老板推荐这么干。虽然我坚信，这是可行的。

或许在您的项目中，已经成功地应用了TDD，那么希望您能够分享您的经验。如果您经历的大型项目正在使用TDD，那么我们所有的读者都将非常感兴趣。

希望本文有任何不足之处，都请与我联系，在我的Blog上留言或给我发邮件：sslaowan@gmail.com

Your Design Values

驱动……发现你的设计价值

Rebecca J. Wirfs-Brock

There will be variations of everything forever. … Ideas don’t disappear. They change form,

they merge with other ideas. —Bob Frankston, coinventor of VisiCalc

万物永远都是变化的……思想没有消失。它们改变了形式，它们并入了其他思想。——Bob Frankston，VisiCalc发明者

Today we have design or development approaches that are, for example, responsibility driven (RDD), test driven (TDD),behavior driven (BDD), domain driven(DDD), and model driven (MDD). Not all thought leaders in software development have been “driven”—Bertrand Meyer, for example, invented Design by Contract. But whether “driven” or not, these approaches all emphasize a core set of values and principles around which practices, techniques, and tools have emerged.

  今天我们拥有的设计或开发方法是，举个例子，责任驱动（RDD），测试驱动（TDD），行为驱动（BDD），领域驱动（DDD）和模型驱动（MDD）。并不是软件开发中的所有领导者都是“驱动”的——比如Bertrand Meyer发明的契约式设计。但是无论是不是“驱动”，这些方法都强调了一组围绕已经出现的实践、技术和工具的核心价值和准则。  

   A thoughtful designer should be able to pick and choose among practices without losing their essence. But not all practices are congruent. After stewing in this alphabet soup for years, I’m keen on exposing the common and complementary threads that are interwoven among various design practices.

   一个有思想的设计者应该能够在这些实践中挑选而不失去它们的本质。但是不是所有的实践都是适合的。在这个字母汤里煮了多年之后，我热衷于揭示交织在各种各样的设计实践中的共通之处和补充内部。

Responsibility-driven design

责任驱动设计

    So how can you integrate various practices without watering them down or muddling your thinking with too many considerations? It’s certainly easy if you have one belief system with one small set of coherent values and practices that guide your work. In 1989, Brian Wilkerson and I authored the paper “Object-Oriented Design:A Responsibility-Driven Approach.”1 For better or worse, we started the trend of tagging design approaches as “driven.” To make our point, we oversimplistically divided object design approaches into two camps: those that focus first on structure and those that focus first on action (or responsibilities or behaviors). We argued that designers who first focus only on an object’s structure fail to maximize encapsulation.

Thinking too early about structure makes it too easy for implementation details to bleed into class interfaces.

    所以你怎样将各种不同的实践整合起来而不会由于有太多需要考虑的事项将它们全都随水一起倒掉或搞乱你的思想？如果你有一个信任系统和一小套一致的价值和实践指导你工作，那么这确实很容易。在1989年，我和Brian Wilkerson写了名为“面向对象设计：一种责任驱动的方法”的论文。为了更好或更糟，我们开始倾向于给设计方法贴上“驱动”的标签。为了声明我们的观点，我们过分单纯的将对象设计方法分为两个阵营：一派首先关注结构，而另一派首先关注动作（或责任或行为）。我们认为首先只是关注一个对象的结构的设计者未能实现最佳的封装。过早的考虑结构会导致过早的将实现细节侵染到类接口。

We contrasted two approaches for designing a RasterImage class that represented a rectangular grid of pixels. (We wrote this paper when raster technology was new, and at the time we both worked at Tektronix, a leading provider of graphics workstations.) With a data-first approach,we started defining our RasterImage class by declaring the image data structure and then adding methods to retrieve and set the image and query its dimensions. Voila!—a class where form and function were inextricably intertwined.

我们对比两种设计表现像素的一个矩形栅格的RasterImage类的方法。（我们写这篇论文时，光栅技术还是新的，那时我们一起在Tektronix工作，Tektronix是图形工作站的主要提供商。）用数据先行的方法，我们开始定义我们的RasterImage类，我们声明镜像数据结构，然后添加方法去重新得到和设置镜像，查询它的尺寸。瞧！——一个外形和功能避免不了的纠缠在一起的类。

The pixel grid data structure wasn’t considered a private implementation detail.Next, we demonstrated how a designer could think differently about the problem by asking,“What actions could this object be responsible for?” and “What information should it share with others?” This led us to first define operations for our RasterImage class to scale and rotate the image and access pixel values. The internal image  representation, which we didn’t specify until after we’d defined the interface,was considered a private detail.

这个像素栅格数据结构不是被考虑成一个私有的实现细节。下一步，我们证明一个设计者能够以不同的方式来思考问题，通过询问“这个对象对于什么动作负责任？”和“它和别人共享什么信息”。这引导我们首先定义我们的RasterImage类的操作来测量和旋转镜像和访问像素值。我们在定义接口之前没有指定的内部镜像表示被考虑成一个私有细节。

By consciously assigning most objects actionoriented responsibilities, you can design even seemingly  data-centric objects to perform some actions as well as encapsulate structural details.

DESIGN

1 0 IEEE SOFTWARE www.computer.org/software

Hiding that structure makes those de­tails easier to change. To us it seemed that the order in which a designer con­siders things profoundly affects the re­sulting design—even for a class as straightforward as RasterImage. To quote Samuel Alexander, the philoso­pher, “An object is not first imagined or thought about and then expected … but in being actively expected it is imagined as future and in being willed it is thought.”

通过自觉地分配给大多数对象面向动作的责任，你甚至能够设计看起来以数据为中心的对象来执行一些动作和封装结构的细节。隐藏结构使那些细节容易改变。对于我们而言，看起来一个设计者考虑事情的顺序深深的影响作为结果的设计——甚至对于一个像RasterImage一样简单易懂的类。引用哲学家Samuel Alexander的话，“一个对象不是先被想像或思考然后被期望……但是由于积极的被期望，它被想像成未来，由于有某种意志，它是思想。”

 Since those early days I’ve added the notion of role stereotypes, ² acknowledg­ing that not all objects are active. Infor­mation holders—objects with responsi­bility for maintaining data—have a place in a design, too. But encapsulating their private details is important.

  自从那些早些的日子我添加了角色构造型的概念，知道不是所有的对象都是有效的。信息持有者——具有持有数据责任的对象——也在一个设计中有一席之地。但是封装它们的私有细节是重要的。

Test-driven design

测试驱动设计

  RDD evolved in the highly interactive world of Smalltalk development, where developers routinely designed a little, coded a little, and tested a little in short cycles. The delightful tension of cycling between imagining what an object might do, building it, and then refining your ideas and cycling through your design again can lead to deep insights. This has led agile-programming thought leaders to promote test-driven development practices. Test-driven design emphasizes deciding on an interface and then writ­ing code to test that interface, before im­plementing code to make the interface pass the test.

 RDD在高度互动的Smalltalk开发世界进化，在那儿开发者例行公事的设计一小块，编一小段代码，然后再很短的周期里做少许测试。在想象一个对象做什么，然后构建它，然后精化你的想法之间循环的令人愉快的压力而且循环通过你再一次设计能够使你有更深的理解。这引导敏捷开发思想的领导者提倡测试驱动开发实践。测试驱动设计强调动对一个接口作出决定，然后编写代码去测试那个接口，在实现代码之前使接口通过测试。

In Test-Driven Development by Example, Martin Fowler claims that TDD “gives you this sense of keeping just one ball in the air at once, so you can con­centrate on that ball properly and do a really good job with it.”³ With a design­test-code-reflect-refactor rhythm, good code emerges alongside well-designed interfaces.

在Test-Driven Development by Example中，Martin Fowler声称TDD“给你这种保持一次只有一个球在空中的感觉，所以你可以完全集中精力在那个球上和使用它真正地做好一件事。”带着一种“设计测试-编码-反馈-重构”的节奏，好的代码在一旁显示出设计良好的接口。

Linda Crispin explains that TDD isn’t really about testing.⁴ Instead, it’s a prac­tice that gets you thinking about as many aspects of a feature as you can be­fore you code it. With frameworks such as Fit and Fitnesse, TDD has extended beyond its initial focus on just develop­ers to enable nontechnical people to write concrete examples of inputs and expected results in tabular form. Programmers write test fixtures that use these behavioral specifications to test the code.

Lina Crispin说明TDD其实不是关于测试的。相反，它是一种使你在编码之前尽可能考虑一个特征的许多方面的实践。使用像Fit和Fitness这些框架，TDD扩大了它最初的关注范围，那时它只关注开发者使非技术人员能够在表格中写出具体的输入样板和期望的结果。程序员编写测试装置来测试代码，测试装置使用这些行为的详细规格说明书。

 As TDD practices have grown, new variants of them, along with newer test­ing frameworks, have emerged. Users of jMock use mocks that mimic unimple­mented behaviors to drive out an appro­priate distribution of responsibilities among collaborators .⁵ They don’t think that it’s just about testing, either. Mock­ing lets you incrementally design and build software, hypothesizing and refin­ing your ideas as you go.

 作为一个TDD实践者已经成长，它们中的新的变体和更新的测试框架已经形成。jMock的使用者使用mocks来模仿未实现的行为来完成在协作者中一个适当责任的分配。他们不认为只是测试。Mock让你增量的设计和构建软件，当你前进时假定和精炼你的想法。

Behavior-driven design

行为驱动设计

 BDD is another subtle refinement of TDD. BDD proponents firmly believe that how you talk about what you’re do­ing influences how you work. The focus is on writing small behavior specifica­tions to drive out the appropriate design. As Dave Astels puts it, “A major differ­ence is vocabulary. Instead of subclass­ing TestCase [as you would do using an xUnit framework], you subclass Con­text. Instead of writing methods that start with test, you start them with should.”6 Testing, to BDD proponents, connotes verifying code after it’s built. Instead, they want to encourage incre­mental design by writing small specifica­tions, then implementing code that works according to spec.

BDD是TDD另一种的细微的改进。BDD支持者坚定的相信你如何讨论你正在做的事情会影响你如何工作。焦点是编写小的行为规范来导出合适的设计。当Dave Astels提出它时，“一个主要的不同是词汇。代替子集化TestCase [当你使用一个xUnit框架时]，你子集化上下文。代替书写使用测试开始的方法，你使用意愿开始。”测试，对于BDD的支持者，意味着在构建之后检验代码。相反，他们想要鼓励增量设计通过书写小的规格说明书，然后实现按照规格说明书工作的代码。

Does every method
warrant a contract?
Probably not. Methods
that don’t cause side
effects probably don’t
need contracts.

Design by Contract

契约式设计

In contrast, Design by Contract (DbC) has roots in formal specifica­tions. To specify how they expect sys­tem elements to interact, designers write contracts specifying what must be true before a module can begin (precon­ditions), what must be preserved during its execution (invariants), and what it guarantees to be true after it completes (postconditions). You could specify con­tracts for components, services, or even individual methods. However, in prac­tice, most contracts are written at the method level because existing program­ming languages and tools support work at that level. Writing contracts is easier if the languages and tools you use sup­port them and you have good examples to emulate. The Eiffel language inte­grates contract support into the lan­guage and runtime environment; most other object-oriented languages don’t.

与之对照的，契约式设计根植于正式的规格说明。为了指出他们期望系统要素如何相互作用，设计者撰写契约详细说明在一个模块开始之前什么是必须正确的（前置条件），在执行时什么是必须保持不变的（不变式），在它完成之后它保证什么是正确的。你应该详细说明组件、服务或者甚至是单独的方法的契约。然而，在实践中，更多的契约是在方法级上书写的，因为既有的编程语言和工具支持工作在那个层面上。如果你使用的语言和工具支持他们而且你有好的例子仿效那么撰写契约是更容易的。Eiffel语言将契约支持整合进语言和运行时环境；大多数其他的面相对象语言不具备这种支持。

Before looking at Contract4J, a DbC tool for Java, I thought that spec­ifying contracts for languages without built-in support would be clunky. However, using aspect technology, Contract4J automatically weaves as­pect-specific contract tests, which are specified in method comments, into your running code. Contracts specified this way leave method code unclut­tered with assertion statements and leave a nice documentation trail of how methods should be invoked.

在看到Contract4J（Java的DbC工具）之前，我认为为一种语言指定契约而没有内置的支持将会非常郁闷。然而，使用方面技术。Contract4J自动将细节方面的契约测试织入你运行的代码，它在方法注释中被指出，被这种方式指出的契约使用断言声明使方法代码保持整洁，保留一份好的文档跟踪方法是如何被调用的。

If you choose to, you could apply TDD practices to understand your classes’ behaviors and then add contracts to methods whose behaviors you want verified at runtime. But I suspect these two communities differ considerably in their thinking. Some TDD proponents want to discourage after-the-fact verifica­tion, which to them seems antithetical to designing for quality. But adding con­tracts does tighten up how you use classes, theoretically making it easier to catch errors before they propagate.

如果你做出选择，你可以应用TDD实践理解你的类的行为然后将契约加入到你想要在运行时检验其行为的方法中。但是我怀疑这两个社区在他们的思想中相当不同。一些TDD支持者反对事后检验，这对他们而言看起来与为了质量设计是对立的。但是增加契约加强了你如何使用类，理论上使它更容易在他们传播之前捕捉到错误。

   When you change your design, sometimes contracts will naturally change, too. But once your design ideas settle down, you can finalize or add contractual details. But does every method warrant a contract? Probably not. Methods that don’t cause side ef

DESIGN

fects probably don’t need contracts. But I know I’d certainly find it easier to use class libraries if contract specifications were part of their documentation even if they weren’t validated at runtime.

    当你改变你的设计，有时契约也将自然的改变。但是一旦你的设计想法稳定下来，你能够最终定下来或者添加契约的细节。但是每一个方法都保证一份契约？或许不是这样的，不会导致副作用的方法或许不需要契约。但是我知道我的确发现如果契约详细规格书是它们的文档的一部分就更容易使用类库，即使他们不在运行时被验证。

Domain-driven design

  What about incorporating DDD ideas into your design practice? Accord­ing to Eric Evans, DDD isn’t a technol­ogy or methodology but “a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains” (www.domainlanguage.com/ddd/ index.html). A central activity in DDD is searching for the language that experts use to talk about the problem and then literally reflecting that language in classes and services in a domain layer. Eric be­lieves that, “If developers don’t realize that changing code changes the model, then their refactoring will weaken the model rather than strengthen it.” Creat­ing a domain model is intricately tied to expressing it in working code. Domain­driven design is an active, ongoing process of expressing this domain lan­guage in code.

 怎样把DDD想法融入到设计实践中？按照Eric Evans的说法，DDD不是一项技术获方法论而是“一种思考方式和一组优先级，目的在于促进不得不解决复杂领域的软件项目”。在DDD中一项核心活动是寻找专家用来讨论问题的语言，然后逐字的将那种语言反映到位于领域层的类和服务中。Eric相信，“如果开发者不了解改变代码时改变模型，然后他们的重构将削弱而不是增强模型。”创建一个领域模型杂乱的在工作着的代码中被依靠表达它。领域驱动设计是一种积极的、正在进行的使用代码表示领域语言的过程。

Model-driven design

模型驱动设计

In contrast, adherents of MDD (some call it model-driven engineering to avoid the Object Management Group trademarked term) first develop a plat­form-independent model of their system (usually in UML or a domain-specific language) before translation tools trans­form the model into platform-specific code. MDD practitioners strive to clearly represent system concepts and behaviors with the goal of producing an abstract model, not working code (the translation tools do that for them). This view of model building followed by transformation probably causes the great divide between MDD practition­ers and other design schools—even though they share many common de­sign values. After recently listening to and talking with several well-known MDD proponents who were discussing what constitutes well-designed classes, methods, and components, I found my­self nodding in agreement with many of their design guidelines.

与之对照的，MDD的拥护者在使用转换工具将模型转换成具体平台代码之前，先开发一个他们系统的平台无关模型（通常使用UML货一种领域规范语言）。MDD开创者们带着生产一个抽象模型而非工作的代码（转换工具替他们来做生产代码的事情）的目的，努力清晰的表现系统概念和行为。模型遵循转换构建的观点或许导致了MDD开开创者与其他设计学派的巨大分隔——即使他们共享许多通用设计价值。在最近听到和与许多不同的众所周知的MDD支持者（他们正在讨论什么构成了良好设计的类、方法和组件）讨论之后，我发现自己非常赞同他们的设计指导思想中的很多内容。

ow you design should be based on your principles and values. Al­though a big division exists between those who believe the act of coding is what validates the design and those who don’t, you can learn many things about good design from each. My mantra has always been, “Be open to new ideas and techniques that make me a better de­signer.” I side with Canadian politician Dan Miller, who proclaims, “You know, we have our differences, everybody does, honest, real differences, but I do believe strongly that we as neighbors are drawn together far more than we’re dri­ven apart.”

     如何设计，你应该基于你的原则和价值。尽管有巨大的区别存在于那些确信代码的行为是检查设计的标尺的人们和他们的反对者中，但是你从他们中能够学会许多优秀设计的东西。我的箴言一直是，“善于接受新观点和技术，使我成为更优秀的设计师”。我和加拿大政治家站在一起，他宣称，“你知道，我们有不同，每个人都一样，诚实的，真实的不同，但是我深信作为邻国我们的共通之处远远多于我们的区别。”

References

 1. R. Wirfs-Brock and B. Wilkerson, “Object-Oriented Design: A Responsibility-Driven Ap­proach,” Proc. 1989 ACM SIGPLAN Conf.

Object-Oriented Programming, Systems, Lan‑

guages, and Applications (OOPSLA 89), ACM Press, 1989, pp. 71–75.

2.    R. Wirfs-Brock, “Characterizing Classes,” IEEE Software, Mar./Apr. 2006, pp. 9–11.

3.    M. Fowler, Test-Driven Development by Ex­ample, Addison-Wesley, 2003.

4.    L. Crispin, “Driving Software Quality: How Test-Driven Development Impacts Software Quality,” IEEE Software, Nov./Dec. 2006, pp. 70–71.

5. S. Freeman et al., “Mock Roles Not Objects,” Companion to 19th Ann. ACM SIGPLAN

Conf. Object-Oriented Programming, Sys‑

tems, Languages, and Applications (OOPSLA 04), ACM Press, 2004, pp. 236–246; www. jmock. org/oopsla2004.pdf.

6.    D. Astels, “A New Look at Test-Driven Devel­opment,” http://blog.daveastels.com/files/BDD _Intro.pdf.

Rebecca J. Wirfs-Brock is president of Wirfs-Brock Associates and an adjunct professor at Oregon Health & Science University. Contact her at rebecca@wirfs-brock.com.