1.3.2 DI应用（1）

作者: [美]Craig Walls Ryan Breidenbach著/毕庆红/王军等译 出处:人民邮电出版社 　2008-07-25 13:33　   砖    好    评论  条 　进入论坛

阅读提示：《Spring in Action（第二版）中文版》第1章开始Spring之旅,这一章主要讲述的是Spring核心模块、解耦应用对象和使用AOP管理交叉问题，本小节为大家介绍DI应用。

1.3.2  DI应用（1）

假设你们公司最棒的销售团队聚集在一起交流他们的专业市场分析及研究结果，最后认为客户最需要的是骑士。也就是说，他们需要一个Java类来表示一个骑士。在考察了他们的需求后，你知道了他们的确切需求对你来说就是实现一个类，用它表示亚瑟王的圆桌骑士，这些骑士勇敢地从事着寻找圣杯的神圣任务。

这是一个奇怪的需求，但是你已经习惯了市场部的古怪想法和念头。所以，你毫不犹豫地打开喜爱的IDE，匆匆完成了程序清单1.5所示的这个类。

程序清单1.5 圆桌骑士Bean

在程序清单1.5中，骑士有一个以姓名作为参数的构造方法。这个构造方法实例化一个HolyGrailQuest，并将它当做骑士的探险任务。HolyGrailQuest的实现很简单，见程序清单1.6。

程序清单1.6  赋予骑士的Holy Grail bean查询

你对自己的工作很满意，自豪地将代码提交到版本控制服务器上。你想把它展示给市场部人员，但是感觉有些不对劲的地方。在意识到尚未写任何单元测试之前，你几乎是胸有成竹。

测试骑士

单元测试是软件开发的一个重要部分。它不但保证每个单元能如期工作，而且，它可以看作是每个单元的最准确的文档。为了矫正疏忽单位测试的失误，你为骑士类汇总了测试用例（见程序清单1.7）。

程序清单1.7  测试骑士

写完这个测试用例之后，你开始为HolyGrailQuest编写测试用例。但是在开始之前，你认识到KnightOfTheRoundTableTest测试用例间接地测试了HolyGrailQuest。你也想知道是否测试了所有的情况。如果HolyGrailQuest的embark()方法返回null或抛出GrailNotFoundException，会发生什么？

谁调用谁？

目前KnightOfTheRoundTable的主要问题是它如何获得HolyGrailQuest。不管它是通过实例化一个新的HolyGrail得到，还是通过JNDI得到，每个骑士都要自己负责获得探险任务（如图1.3所示）。所以，无法完全孤立地测试骑士类。事实上，每次当你测试KnightOfTheRoundTable的时候，你就间接地测试了HolyGrailQuest。

而且，你无法让HolyGrailQuest为不同的测试做不同的动作(如返回null或抛出GrailNotFoundException) 。如果你能创建一个HolyGrailQuest的模拟实现，由你决定它的动作，这样或许能有帮助。但既使你创建了一个模拟实现，KnightOfTheRoundTable得到的仍然是它自己的HolyGrailQuest。这意味着你必须为测试而修改KnightOfTheRoundTable（以后产品发布还要改回去），以得到模拟的Quest。

图1.3  骑士类通过实例化或其他方法自己得到它 的探险任务

使用接口解耦合

一言蔽之，现在的问题是耦合。从这个观点看，KnightOfTheRoundTable与HolyGrailQuest紧密地耦合在一起。他们被紧紧地绑在了一起，以至于有一个KnightOfTheRoundTable就一定有一个HolyGrailQuest。

耦合是一个双头怪物，一方面，紧密耦合的代码难以测试，难以重用，难以理解，带来典型的“摧毁大堤”bug（如修改一个bug会引来另一个或更多的 bug）。另一方面，完全没有耦合的代码什么也做不了。为了做一些有意义的工作，类必须以某种方式知道其他类的存在。耦合是必须的，但需要小心管理。

减少耦合的一个通常的做法是将具体实现隐藏在接口下面，这样具体实现类的替换不会影响到引用类。例如，假设你要创建一个Quest接口：

现在，让HolyGrailQuest来实现这个接口。同时注意，embark()方法返回的是一个Object并且会抛出QuestFailedException异常。

同样，为了与这个Quest接口兼容，KnightOfTheRoundTable的方法也要加以修改：

同样，你也要让KnightOfTheRoundTable实现下面的这个Knight接口：

回书目   上一节   下一节