论道WP(三):应用程序栏
作者通过具体翔实的例子介绍了Winodws Phone 7中应用程序栏的使用方式。
该内容已经被标记书签!
标记书签错误,请重试!

作者 Dionysios G. Synodinos 译者 曹云飞 发布于 2010年1月7日
Dhanji R. Prasanna的著作《依赖注入》是一本力图详细探究依赖注入领域,并呈现Spring和Guice技术的著作。Dhanji是Google的一名软件工程师,从事Google Wave的研发,并对Guice、MVCL和其它开源项目做出了贡献。
本书分为11个章节:
在两节附录中还讨论了其他依赖注入框架,用于Flex的SmartyPantsIOC以及Butterfly容器。
本书的出版商Manning为InfoQ提供了第3章的内容,标题是‘研究DI’ 。
InfoQ就这个书采访了作者:
InfoQ:你好Dhanji,你能简单介绍一下自己以及为何会写一本关于DI的书么?
Dhanji:当然。我是在Google的一名软件工程师,我的日常工作是Google Wave产品,在空闲时间我致力于Google Guice和MVEL——针对Java的表达式语言。我还在Servlet和JAX-RS专家组代表Google发言。
最初有另外一家小出版社联系我写一本Guice的小册子。那时候,我的好朋友(Apache Wicket的开发者)Eelco Hillenius正在为Manning写Wicket in Action,他让我和Manning的人交流,他们建议我写一本更综合的关于设计模式和软件工程的书,这对我很有吸引力,我也更乐意写一本不偏倚于任何框架的书。
InfoQ:什么是“依赖注入”,它所致力解决的问题是什么?
Dhanji:非常简单的说,依赖注入的思想是不去主动获得你需要的东西,而是相反,你自己作为一种服务,让需要的东西来找 你。该模式的核心是将一个服务与它所依赖的其他服务解耦,这样一来,那些依赖可以替换为测试用的mock对象,或者针对其他环境替换为恰当的变体。通过保 持对于所依赖对象的不可知性,一个服务是高内聚的,功能专一的并且易于进化的,这一切都是通过坚持一个良好定义的契约实现的。
在书中我探索了与依赖注入相关的以及可能用于通用应用架构的多种设计模式。框架为日常编程工作提供了许多模式本身没有提供的增强功能。所以,本书中对依赖注入的彻底研究,在广义上是真正的对应用架构和设计的研究。我希望本书的副标题(设计模式)传达了这一信息。
InfoQ:在第9章你说“由一种语言以及它的工程基本原理预示的最佳实践,与依赖注入提出的最佳实践是相同的”。这个观点使得依赖注入的新老用户都有点困惑,你可以详细说明其含义么?
Dhanji:这与我之前的观点非常相似——那就是,这本书真正的是关于良好的应用设计与架构的。工程基本原理例如严格类型、松耦合、模块化设计以及组件重用也是依赖注入技术所鼓励和宣传的基本要素,尽管后者是使用声明式API以更有组织的形式表现的。
因此,在使用依赖注入做设计时犯的错误与通常的应用设计的反模式是类似的。我在书中力图搞清楚这些问题,有一章主要关注并发与面向对象的设计,这些在依赖注入中是要点,但是通常没有这样关联起来考虑。
InfoQ:Bob Lee,Guice的创建者在介绍你的书的时候说对依赖注入的支持最终会成为另一个语言特征,“一个导入实例对象的构造器”。你如何看待这个观点?
Dhanji:我同意Bob的说法。在今天没有某种依赖注入的库的支持就开始写一个大型应用是难以想象的。几乎所有的现代企业框架都有一个核心的依赖注入组件。我认为甚至EJB现在也有类似的机制。
目前有一个更根本的议题,依赖注入是语言缺乏该功能的一种解决方法。它的确通过减少重复代码和使得代码更经得起变化给我们带来了巨大的好处,最终一门完备 的语言不应该需要这样的第三方库。Bob的观点是我们最终会将依赖注入作为平台自身的一部分,而不是将它作为第三方的框架纳入平台。就如同今天你使用集合 类一样使用依赖注入。
InfoQ:在你的书中你列出了使用依赖注入的几种最佳实践和模式。你曾经看到过哪些人们误用依赖注入和依赖注入框架的方式(反模式)?
Dhanji: 噢,我看到过很多这样的例子!在我的书中警告的所有反模式都来自于真实的工作中的经验。我想主要问题是当人们将依赖注入看作一把锤子,所有的东西都变成了 钉子。方便的支持面向方面的编程(拦截方法调用和修改对象行为)可能是依赖注入框架的功能中被滥用的最严重的。当人们看到某些事情成为可能时十分兴奋,经 常会忽视可维护性、他们本来力图要解决的问题以及依赖注入可以解决的问题。
除了炒作之外,你不需要在所有看到“new”操作符的地方使用依赖注入。
InfoQ:你希望依赖注入框架向什么方向发展?你认为什么会是在将来可以期待的?
Dhanji: 我希望看到更多模块化的扩展以及对早期错误检测的更多关注。我们有一些分析工具用来描述和分析应用结构(例如,Guice的grapher)。我们小心地在Guice内部支持这个功能,我觉得将来在减少样板代码和潜在错误这个方面大有可为。
在扩展模块方面,我们计划支持统一的应用生命周期,扩充错误检查和针对web应用的更好的严格类型。我希望所有的依赖注入框架在这方面大步的进化,而不是急于支持一些花哨的功能或者当前的习惯。
InfoQ:在你的书中你提到依赖注入框架已经进化了,它们已经在更好的利用领域特定语言了。你可以就此给出详细一些的解释么?
Dhanji:领域特定语言(DSL)现在很时尚,尤其是在API设计方面,DSL已经被大量采用。然而,撇开时尚不 谈,DSL在捕获声明意图方面非常简洁有用。依赖注入框架所做的许多事情(绑定实现细节,AOP拦截,范围)是描述性的一系列声明语句或者目标。在这个意 义上,DSL在配置一个依赖注入框架方面是非常有用的。Guice使用一个内嵌的DSL(有时候叫做内部的DSL)来捕获配置,该DSL基本上是一个模仿 一个特定语言的Java构造器对象。在Guice 2.0中我们支持一个DSL可以在web应用中将servlet和过滤器映射到URL路径。
InfoQ:你可以告诉我们一些关于在Google使用依赖注入的情况么?如我在你的书中读到的,Guice应用在一些像Google Wave这样高调的产品中。
Dhanji:在Google我们有非常严肃的测试。因此依赖注入几乎是每个工程师工具箱中的核心概念。今天在Google 所有的Java应用都是Guice应用。我们已经发现它的特征(例如类型安全、早期检测和关注模块化)在构造大型的、可维护的应用方面是非常重要的。在公 司到处都有减少样板代码,让新来的工程师易于上手并学习遗留代码内部工作机制方面的成功案例。
在Google Wave中,我们几乎在应用的所有部分使用了Guice,包括新的servlet模块,该模块已经彻底消除了对servlet和过滤器的基于xml配置的 需求。我们在开发过程中体会到顺畅的、模块化的Java程序是很容易合理化和设计的。例如,我们可以划分、合并、插入各种各样的涉及认证和站点安全的服 务,如同处理Guice的servlet模块一样简单。
这使得Wave灵活并且可以适应所有安全和用户加载的需求的变化。
InfoQ:最近关于JSR-330(“Java依赖注入”)与JSR-299(“上下文与Java EE平台的依赖注入”)的争论很激烈。你如何看待这场争论?
Dhanji:很久以前(那时这个领域还很年轻),我与Larry Cable、Rod Johnson、Bob Lee和其他人一起努力标准化依赖注入。那次努力没有得到我们期待的结果,所以我很乐于看到这事再度发生。
按照我的理解,JSR-330处理Java SE的基本依赖注入而JSR-299为Java EE容器增加了一套完整的、额外的服务。混乱最初是由一个JSR的变化与另外一个JSR一次晚些的不经意提交引起的。我相信两个JSR的规范负责人现在正在一起工作来达成一个令双方满意的结论,299将建立在330的基础之上。
我个人不再使用Java EE而且也没有卷入任何一个规范,所以我对于它们没有深入的研究。
InfoQ:现在有一些关于依赖注入框架的著作,但是你的书采用了与其它书不同的方法,每当在深入框架支持之前,你会呈现依赖注入背后的基本概念。你认为对于初识依赖注入的读者来说什么是书中最值得读的部分,对于有依赖注入框架经验的读者来说哪些内容是可以帮助他们更上一层楼的?
Dhanji:我希望人们更多的考虑设计。如果我的书揭示了如何谨慎做出良好的可重用并且简明的设计,那我会非常高兴。依赖注入只是进入构建应用艺术的一扇窗——我要非常清楚地强调这一点,构建应用是艺术,不是科学。达到模块性、性能和可读性的最佳平衡点是非常困难的,只有通过大量实践和经验才能掌握该艺术。我在写着这本书的过程中以及我的职业生涯中犯了很多错误,这些错误对于教导我理解设计问题是怎样出现的以及如何规避设计问题是最宝贵的。
你可以在InfoQ的依赖注入,Guice和Spring专辑找到更多信息!
查看英文原文:Book Excerpt and Interview: Dependency Injection。
感谢张凯峰对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。
RT
哈哈,肯定有,Google下吧:)
ss
你这问的太明目张胆了, 我们要支持正版!
有兴趣翻译的,可以与我联系。
哈哈,我们(InfoQ China)替大家要来了5份这本书的电子版,想要的同学,就在下面留言吧~
跪求一份电子版来学习下,simazhuo@sohu.com
我要电子版!
我想要一份这5份这本书的电子版,我的邮箱是:cmjandzyh@163.com,兄弟在此先谢谢你了!!
很想要啊!能给一份不:wlq_funylife@163.com,谢谢!
我也想要一份电子版,我的邮箱:qiyufang2005@163.com 谢谢了!
不知道有没机会看看呢
抽中我吧,,,~~~
大家拿到电子书的分享下哇~
求电子版gzg257@163.com
想看看这本书。
你好!我想要这本书的电子版,邮箱是huanghonggen01@sina.com
请给我也发一份,franklinyang85@gmail.com
ps.5份?限量?
很想要啊! benjust@163.com ,谢谢!
谢谢 刘总 我也要一份 mlh123caoer@gmail.com
我也想要一份这本书的电子版,跪求。我的邮箱是:gyhlhj103924@163.com,兄弟在此先谢谢了,
想要来一份 学习学习 thanks1949@gmail.com
想看,先报名
alex.soog@gmail.com
我要。。。
dollyn.sun@gmail.com
dollyn.sun@gmail.com
这本书看介绍会不会有点太长,有点过多抠虚的东西,从而不够实用?等看过就能知道了。
RT
哎呀,我可是回复的发起人啊,真的有电子版,能给我一份吗?中英文都可以。
nbby1011@163.com
谢谢,超级想要一份。scott.cgi@gmail.com 谢谢
蛾~..这多人啊.
jmujmu@gmail.com
报名,邮箱 bingsun8208@gmail.com
超级像要一本,给我发一本,jgpycj@yahoo.com.cn
huang.x.hui@gmail.com
流传开只是时间问题
sabrina_yun0625@163.com
我也想要一份:starslover@foxmail.com
有偿翻译?
我对本书比较感兴趣,希望有机会得到电子版看看!
Google一搜就能找到,还在这里砌墙,Google可以走了,搞技术的都不会用,还留下干什么嘞?
Google一搜就能找到,还在这里砌墙,Google可以走了,搞技术的都不会用,还留下干什么嘞?
兄弟,你搜到这本电子书了?
我们随机在文章下的留言中抽取了5位,获奖名单如下:
1、2010年1月8日 上午3时49分 发表人 wei wei
2、2010年1月12日 下午8时24分 发表人 琦 王
3、2010年1月12日 下午11时34分 发表人 Grant Huang
4、2010年1月13日 下午9时6分 发表人 Karl MA
5、2010年1月17日 上午1时1分 发表人 伟 宋
请以上5位获奖者,单独给我发邮件(liushen at cn.infoq.com),并注明在InfoQ中文站上的注册邮箱。我会把下载代码,分别发给各位。
我也想要。
leiyanjunai@vip.qq.com
谢谢!
在多线程并发编程中Synchronized一直是元老级角色,很多人都会称呼它为重量级锁,但是随着Java SE1.6对Synchronized进行了各种优化之后,有些情况下它并不那么重了,本文详细介绍了Java SE1.6中对于锁的性能优化,以及锁的存储结构及升级过程。
本次分享将首先介绍现代富文本编辑器的组成和实现,然后结合UEditor的开发过程,与参会者分享UEditor在设计和实现的过程中,所涉及到的核心功能的细节实现。
本次演讲视频录制于百度技术沙龙。
我们所开发的应用程序大多都需要提供一个图形用户界面(GUI)。关于GUI应用的架构设计,已经有了Form & Control、MVC,、MVP、 Passive View等多种模式。模式可以帮助我们建立优雅的架构,但前提是弄清楚模式的应用场景。弄清楚GUI应用面临的设计上的问题,有助于我们正确的挑选设计方案。
MongoDB是一种非常易用的NoSQL方案,Brian C. Dilley在这篇文章里介绍了MongoDB的优劣势,并介绍了MJORM项目。MJORM用于MongoDB,是一个没有注解的Java ORM库。
随着网络基础设施的逐步成熟,从RPC进化到Web Service,并在业界开始普遍推行SOA,再到后来的RESTful平台以及云计算中的PaaS与SaaS概念的推广,分布式架构在企业应用中开始呈现出不同的风貌,然而殊途同归,这些分布式架构的目标仍然是希望回到建造巴别塔的时代,系统之间的交流不再为不同语言与平台的隔阂而产生障碍。
精益软件开发方法因其对市场和交付的重视和在各种场景下体现出的适应能力正在获得广泛的关注。特别是在精益创业(Lean Startup)渐渐兴起和技术日新月异的今天,其"极端"的思想也变得越来越必要和可行。 InfoQ就此主题对他做了深入的采访。
43 条回复
关注此讨论 回复