领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
解耦应用与依赖注入框架
作者 Mike Bria 译者 张龙 发布于 2010年1月21日
由于SOA、TDD等众多因素的影响，依赖注入已成为近年来广为接受的软件开发方法，随之而来的则是依赖注入框架的大量应用（尤其是最近Java EE 6所包含的依赖注入）。Bob Martin则通过实例演示了一种解耦应用代码与依赖注入框架的方法。
在Dependency Injection Inversion这篇文章中，Bob大叔总结到：
...我可不想让依赖注入框架的代码散布在我的应用当中。相反，我想解耦框架与我自己编写的代码。
为了阐述这个问题，Martin给出了一个示例，该示例围绕着BillingService类的创建展开，该类的构造方法定义了如下依赖：
public class BillingService {
...
BillingService(CreditCardProcessor processor, TransactionLog transactionLog) {
this.processor = processor;
this.transactionLog = transactionLog;
}
...
}
首先，Martin使用Guice（Google推出的依赖注入框架）创建BillingService类的实例：
public static void main(String[] args) {
Injector injector = Guice.createInjector(new BillingModule());
BillingService billingService = injector.getInstance(BillingService.class);
billingService.processCharge(2034, "Bob");
}
在解释完该段代码的一些细节后，Martin给出这样一个事实：我们不得不显式地让Guice通过injector来创建BillingService的实例。这么做的结果就是：使用BillingService的代码不再依赖BillingService的依赖了（这很好），但却依赖Guice了。
是不是有利就有弊呢？Martin的回答是肯定的：
依赖注入不过是依赖倒置（Dependency Inversion）的一个特殊情况而已。我认为依赖倒置非常重要，因此打算转换对Guice的依赖。我可不想让那么多的Guice依赖搞乱了我的代码。
之后，他向我们展示了如何通过工厂对象来控制并降低应用对DI框架的依赖：
public static void main(String[] args) {
Injector injector = Guice.createInjector(new BillingModule());
BillingService.factory = new BillingServiceFactory(injector);
}
...
// Deep in the bowels of my system.
BillingService billingService = BillingService.factory.make();
billingService.processCharge(2034, "Bob");
为什么这种方式比较好呢，Martin说到：
我喜欢这么做，因为现在所有的Guice代码都放在了同一个地方，而非散布在应用的各个角落，这是通过工厂实现的。不仅如此，如果将Guice替换成其他DI框架，我会明确知道需要修改哪些类以及如何修改他们。通过这种方式达到了应用与Guice解耦的目的。
要澄清的一点是：在所有的示例中，BillingService本身都坚持着依赖注入原则，而BillingService到底使用的是依赖（CreditCardProcessor及TransactionLog）的何种实现其本身是不得而知的。为了说明这一点，他在文章的最后通过JUnit对BillingService进行了测试，在测试中仅仅使用了简单的TransactionLog和CreditCardProcessor实例对其进行注入，最后无论应用使用何种依赖注入手段，测试结果都是正确的。
Gary Bernhardt就这个测试也给出了一篇文章，提到在Java这种静态类型语言中这么做需要慎之又慎，但对于Python之类的动态语言就无所谓了。
你是否使用依赖注入呢？是否使用DI框架呢？不管答案如何，以上这种做法是否与你产生共鸣了呢？
查看英文原文：Decoupling Your Application From Your Dependency Injection Framework
有InfoQ读者对Bob大叔的这种做法提出了不同的观点：
来自InfoQ英文站的读者monser corp说到：
我想知道Bob大叔在过去几年编了多少代码？
恩，这是一种典型的”顾问式“做法：了解一项新技术，拿起来玩弄一下，然后发表在博客上来满足自己的虚荣心。在我做过的很多项目（使用了Spring）中，只有一个类会依赖于Spring：获取Context并启动应用。99.99%的代码都不知道Spring或Guice是啥（如果不是使用了Spring的某些库的话，IoC容器与Log4J根本就没啥区别）。如果真的想将代码与容器解耦，你需要重新考虑设计与实现，而非使用另一个工厂。
作为读者的您有何高见呢？这里，译者推荐您先去阅读Bob大叔的原文，然后将您的高见发表在这里。
译者 张龙 热衷于编程，乐于分享，对新技术有强烈的探索欲，对Java轻量级框架有一定研究。
Spring
发表人
马 运超
发表于
Re: Spring
发表人
wang metis
发表于
Re: Spring
发表人
manqing li
发表于
Re: Spring
发表人
Ma Karl
发表于
好事
发表人
jiang rosen
发表于
5 条回复
关注此讨论 回复