鬼谷子 书摘
Dhanji R. Prasanna的依赖注入 是一本书 试图 详细探讨DI习语，并在Spring和Guice中介绍技术。 丹吉 是一位Google软件工程师，从事Google Wave的工作，还为Guice，MVEL和其他开源项目做出了贡献。
这本书分为11章。
- 第1-4章介绍了可测试性以及使用依赖项注入的原因，其各种设计模式和使用习惯，尤其是如何选择这些模式并将其应用于各种情况。
- 第5-6章重点讨论范围，这是一种在不污染基础结构逻辑的情况下管理状态的方法。 他们还探讨了常见习语的问题，例如静态单例反模式和使用依赖注入的解决方案，并检查了Web应用程序和其他用途的范围。
- 第7章讨论如何通过依赖关系注入器管理应用程序的生命周期。 这涉及向对象发送有关应用程序生命周期中重要事件的通知，并设计自定义生命周期基础结构。
- 第8章介绍了面向方面的编程（AOP），它应用于依赖注入，它旨在节省样板代码并减少出错的风险。 本章很大一部分致力于使用这种强大技术的潜在问题和陷阱。
- 第9-11章研究并发和设计，并研究性能，设计以及与第三方框架的设计集成方面的案例研究。 第11章是一个案例研究，涉及如何使用本书中介绍的概念来构建完整的Web应用程序。
另外，还有两个附录讨论了依赖项注入框架的替代方法：用于Flex的SmartyPantsIOC和Butterfly Container。
该书的出版商曼宁（Manning）向InfoQ提供了一个专家，其中包括第三章“ 调查DI ”的内容 。
InfoQ与作者就他的新书进行了问答：
InfoQ：您好Dhanji，您想告诉我们一些您自己以及您如何撰写有关DI的书吗？
丹吉 ：好的。 我是Google的软件工程师，在我的日常工作中，我在Google Wave上工作，在业余时间，我为Google Guice和Java的MVEL表达语言做出了贡献。 我还代表Servlet和JAX-RS专家组代表Google。
最初，我与另一位出版商联系，写了一本Guice小书。 那时，我的好朋友（和Apache Wicket开发人员）Eelco Hillenius正在为Manning编写《 Wicket in Action》 。 他让我与他们交谈，他们提出了更全面的设计模式和软件工程书籍，这对我更具吸引力。 我也很高兴写一本不偏重任何框架的书。
InfoQ：什么是“依赖注入”，它试图解决的问题是什么？
Dhanji ：简而言之，依赖注入是这样一种想法，即作为一种服务而不是出去寻找所需的所有东西，而是让它们来找您。 从根本上讲，模式只是指将服务与它所依赖的其他服务解耦，以便可以将这些依赖关系替换为用于测试的模拟或其他环境的变体（如果适用）。 通过不依赖于其依赖关系，可以使服务集中，整洁且易于发展，同时遵守明确定义的合同。
在这本书中，我探索了各种与DI相关的设计模式，这些设计模式通常可用于应用程序体系结构。 框架还为日常编程带来了很多增强，而仅模式无法提供这些增强。 因此，在本书的上下文中，对DI的彻底检查实际上是对应用程序体系结构和设计的广义检查。 我希望本书的副标题（设计模式）能够传达这一点。
InfoQ：在第9章中，您支持“某种语言及其工程基础所代表的最佳实践与依赖注入所提供的最佳实践是相同的”。 既然这会使新手和有经验的DI用户都感到困惑，那么您想详细说明一下吗？
Dhanji ：这与我之前提到的观点非常相似-也就是说，这本书实际上是关于良好的应用程序设计和体系结构的。 严格的类型，松散耦合，模块化设计和组件重用等工程基础与DI技术鼓励和传播的基础相同。 不过，使用声明性API时，其组织形式略有组织。
因此，使用DI进行设计时所犯的错误与人们在一般应用程序设计中看到的反模式相同。 我试图在本书中仔细研究这些内容，其中一章主要关注并发和面向对象的设计，这对于DI是必不可少的，但通常并没有如此关联。
InfoQ：Guice的创建者Bob Lee在介绍您的书时说，对DI的支持最终将成为另一种语言功能，即“用于导入实例的结构”。 您对此有何看法？
丹吉 ：我同意鲍勃的比喻。 如今，在没有某种DI库支持的情况下开始编写大型应用程序已经是不可想象的。 几乎所有现代企业框架都具有核心的DI组件。 我了解甚至EJB现在都有类似的东西。
目前还有一个更基本的问题，那就是DI本身就是解决该语言缺陷的一种解决方法。 尽管通过减少重复的代码并使得代码更易于容忍更改确实为我们节省了很多钱，但最终一门完整的语言不需要我们这样做。 Bob的观点是，我们最终将不将DI作为第三方框架，而是作为平台本身的核心部分。 与您今天使用收藏集的方式几乎相同。
InfoQ：在书中，您列出了使用DI的几种最佳实践和模式。 您看到人们滥用DI和DI框架（反模式）的最坏方法是什么？
Dhanji ：哦，我看过很多！ 我在书中警告过的所有反模式都来自现实生活。 我猜主要的问题是，当人们将DI视为锤子时，一切都变成了众所周知的钉子。 对面向方面的编程（拦截方法调用和修改行为）的轻松支持可能是DI框架功能中滥用最多的一种。 人们看到可能的事情时会感到非常兴奋，并且常常看不到可维护的内容以及他们试图解决的原始问题以及DI 旨在解决的问题。
尽管进行了大肆宣传，但您无需在看到的任何地方都用注入替换“ new”运算符。
InfoQ：您希望DI框架朝哪个方向发展？ 您认为将来会有什么期望？
Dhanji ：我希望看到更多的模块化扩展，并更加关注早期的错误检测。 我们使用一些静态分析工具来描述和分析应用程序结构（例如，Guice的绘图仪）。 我们非常小心地在Guice中建立对此的支持，我认为在此方面可以做更多的事情，以进一步减少样板代码和潜在的错误。
至于扩展，我们计划支持统一的应用程序生命周期，并为Web应用程序更好地扩展错误检查和类型严格性。 我希望看到所有DI框架在该领域都有进一步的发展，而不是急于支持当今的精美库或成语。
InfoQ：在您的书中，您提到随着DI框架的不断发展，它们已经在更好地利用领域特定语言。 您想对此进行详细说明吗？
Dhanji ：如今，DSL有点流行，尤其是在API设计中，DSL已经被广泛采用。 但是，除了时髦的性质，它们非常简洁，在捕获声明意图时很有用。 DI框架的许多工作（绑定实现细节，AOP拦截，作用域）可描述为声明性声明或目标的集合。 从这个意义上讲，DSL在配置DI框架时非常有用。 Guice使用嵌入式DSL（有时称为内部DSL）来捕获配置，该配置基本上是模拟特殊语言的Java构建器对象。 使用Guice 2.0，我们甚至支持DSL来直观地将servlet和过滤器映射到Web应用程序中的URL路径。
InfoQ：您想告诉我们一些有关Google如何使用DI的信息吗？ 就像我在您的书上所读到的一样，Guice被用于Google Wave等几种知名产品。
Dhanji ：在Google，我们非常重视测试。 因此，DI是几乎每个工程师工具箱中的核心概念。 如今，Google上的每个Java应用程序也都是Guice应用程序。 我们发现它的功能（例如类型安全，早期错误检测和对模块化的关注）在构建大型，可维护的应用程序中非常宝贵。 我们从公司各个方面获得了许多成功的案例，它们减少了样板，使新工程师更容易上手并学习遗留代码的复杂内部工作原理。
借助Google Wave，我们几乎在应用程序的每个部分中都使用了Guice，包括新的ServletModule，它完全消除了对基于xml的servlet和过滤器配置的需求。 我们从该过程中学到的东西是，惯用的模块化Java更加易于合理化和设计。 例如，我们能够将与身份验证和站点安全性相关的各种服务分隔，组合和引入为简单的Guice servlet模块。
这使Wave变得灵活且适应不断变化的安全性和用户负载要求。
InfoQ：最近， 关于JSR-330（“ Java依赖注入”）和JSR-299（“ Java EE平台的上下文和依赖注入”）之间的冲突引起了很多争论 。 您对此事持何立场？
Dhanji ：很久以前（当时世界还很年轻），我与Larry Cable，Rod Johnson，Bob Lee和其他人一起致力于标准化DI。 这项努力并没有达到我们想要的程度，所以我很高兴看到现在再次发生了事情。
据我了解，JSR-330处理Java SE的基本依赖项注入，而JSR-299为Java EE容器添加了一堆额外的服务。 最初有些混乱是由于一个JSR的焦点更改和另一个JSR的较晚提交。 我相信两个JSR的规范负责人现在正在共同努力，以达成一个令人满意的结论，其中299个将建立在330个之上。
就个人而言，我不再使用EE，并且我也不参与任何规范，因此我对它们周围的细节没有太多了解。
InfoQ：有很多关于DI框架细节的书，但是您的书采用了不同的方法，在每次探究框架支持之前，都介绍了DI背后的基本概念。 对于刚刚发现DI的人们，您认为这是从书中获得的最有价值的收获，对于想要将其带到下一个DI框架的老用户来说，这是什么？
Dhanji ：我希望人们多考虑一些设计。 如果我的书开辟了如何精心设计良好的可重用和简洁的设计，那会让我感到非常高兴。 DI作为概念只是进入创建应用程序艺术的一扇窗口，并且让我非常清楚地强调这一点，它是一门艺术，而不是一门科学。 要在模块性，性能和可读性之间找到最佳结合点是非常困难的，并且只有大量的实践和经验才能实现。 在撰写本书和整个职业生涯中，我犯了很多错误，这些错误对于教我如何以及如何不解决设计问题非常宝贵。
您可以在InfoQ上找到有关Dependency Injection ， Guice和Spring的更多信息！
更新：对本文发表评论的前五（5）个人赢得了曼宁出版社（Manning Publications Co.）的PDF版本。
鬼谷子 书摘
322
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
