模块化Java:声明式模块化
本文是模块化Java系列文章的第4篇,介绍的是声明式模块化。文中描述了组件如何以声明的方式来定义并组织在一起,而无需让代码依赖于OSGI API。
作者 Sadek Drobi 译者 李剑 发布于 2007年10月19日 上午3时35分
用户界面和用户期待,也即用户模型之间的不一致性,是bug的一个重要来源。如果没有面面俱到的信息来描述软件的工作方式,那么用户就会觉得它的行为是不可预知的。Leonardo Vernazzade的观点是,用户和UI所使用的并不是同一种语言,所以需要进行翻译。 他在自己最近的blog上说到,“语言之间的差异越大,翻译时出现的问题也会越多”,同时,为了保证翻译的一致性而带来的测试压力也就越大。所以,在很多 情况下,比较好的解决方式就是提供一个用户模型和用户界面可以共享的“高度抽象的语言”,也就是领域特定语言(DSL)。这可以帮助我们避免翻译和相应的 测试所造成的浪费。Leonardo认为,从更通用的角度来说,提高抽象级别可以减轻测试负担,而且这一做法可以被应用到任何其他模型中,如软件设计、实 现等等:
当你站在合适的抽象层次上表达一些事情的时候,就无需测试了,[……]你会对C#或者Java中的+=运算符进行测试么?反正我不会。
Andres Aguiar也曾经在他的blog上谈论说,如果我们在完善抽象这一方面投入足够的精力,那么就没有必要进行TDD,甚至是单元测试了。但还是有一些问题是需要考虑周全的。
使用DSL来减轻测试的负担,其前提就是要对DSL本身进行彻底的测试。Leonardo Vernazza声称,“在大多数情况下,这比测试所有的用户界面要简单的多,而且工作量也会大大减少”。这种方法会带来“责任的再分配”,把测试的负担转移到DSL的作者身上。不过Gareth Jones相信,“很多DSL的作者都不会用大量的语言变量来测试他们的代码生成器”。
Scott Bellware在Andres Aguiar的帖子后面着重说到, 判断“抽象所固有的最佳层次”并非易事,但Brad Head指出,这正好就是TTD所做的事情:“用‘试试看’来挑战你的设计抽象”。然而Ron Scott却争论说,TDD是用来找出代码中的变化是否造成了破坏的手段。Bellware实际上所强调的是,如果一个经过设计优化的DSL“功能上已经 全部完成,不再变化”,那么要是想通过关注业务或是技术领域来推进DSL的发展的话,那它就无法再像从前一样为我们带来同样的价值。
您是怎样看待抽象 vs. 测试的呢?你认为可以用DSL来减轻测试的负担么?查看英文原文:High abstraction level of DSLs to reduce the testing burden?
编程由编写商业逻辑转为编写书写商业逻辑的DSL,看起来很cool。从逻辑上讲应该会带来更的错误,只不过错误的分布与以前不同了。部分错误转移到DSL中了。这样的情况下出了bug后程序员不仅要在应用中找bug,也要在DSL中找。不要假设DSL没有错误,在真实工作环境中这不成立。
如果只是一个类似于扫雷器的工具,那么TDD还能受到现在这样的重视么?虽然我的TDD经验并不丰富,但是我确实体会到了test是如何drive design的。再看TDD的英文,TEST DRIVEN DESIGH。可将Test Driven看作是对design的修饰。
它的内涵和外延在哪里?如果statically locked down了,那么这个DSL能说是design-tuned吗?敏捷的重要作用是减少浪费,使用DSL,并对其进行设计优化,也应该是为了这个目的。根据边际效应递减原理,优化到某种程度之后,再做新的努力,不但不会提升整体,反而有可能产生新的浪费。也因为如此,文中提到的“如果一个经过设计优化的DSL‘功能上已经 全部完成,不再变化’,那么要是想通过关注业务或是技术领域来推进DSL的发展的话,那它就无法再像从前一样为我们带来同样的价值。”,从约束理论(《拥抱变化》中也有相关内容)来看,要确定当前影响产出的最大瓶颈在哪里,再对症下药。当然,如果是从纯技术的角度考虑DSL的发展,无可厚非,那就不要再幻想它能够像一开始那样带来同样的价值了。
加链接没加上,Amr Elssamadisy 关于约束理论的文章:www.agilejournal.com/articles/articles/theory-o...
我觉得Ron Scott说的就是扯淡
本采访是在伦敦举行的QCon2009上记录的,Ian Robinson和Jim Webber探讨了如何将Web作为整合平台以及REST在理论上和实践中的好处。
项目管理对于项目成败至关重要,但实践中每个项目都有自己的独特性,没有现成的解决方案可以套用。书中从应对实际风险的角度出发,讲述了从项目启动、项目规划到项目结束的整个管理流程,展示了作者的思考过程。本迷你书从原书中精选出5个章节。
在这个演讲中,Fred将会揭示敏捷的一些外在因素,并会重点关注敏捷获得成功的内在原因。从案例研究和真实的项目经验来看,Fred认为:工具、管理体系都不能让你变得敏捷。敏捷的成功,植根于士气高涨、充分授权的工作者身上,他们能够以不同以往的方式思考问题。
Eben Hewitt的新书《Java SOA Cookbook》从Java实现的角度讨论了面向服务架构。Eben在书中讨论了SOA基础、工具、最佳实践和SOA治理等主题。
Mark Richards的新书《Java消息服务》第二版覆盖了JMS的许多主题, 包括发布和订阅模式以及点对点模式,消息过滤和事务等。InfoQ与Mark谈论了跟他的新作。
5 条回复
关注此讨论 回复