读EclipseCon2006相关PPT有感

EclipseCon2006已经结束一段时间了,最近才抽出时间去down下相关感兴趣的PPT来看看,受益不少,N多大师的演讲另人拍案叫绝,不过也有几个PPT让我看的有所疑问,摘录几个PPT的读后感,^_^
1、Best Practices for Programming Eclipse and OSGi
      这个PPT是equinox team leader Jeff的大作,^_^,非常的不错,点出了Equinox中的两个重点,虽然这和PPT的名字有所不同:
      Modularity
     在equinox中可以采用两种方式来实现这点,分别是Require-Bundle和Import-Package的方式,就像Jeff在PPT中所说一样,Require-Bundle适合用于需要引用其他Bundle中的资源的情况,但它就使得bundle产生了紧耦合,所以推荐使用Import-Package,Import-Package保证了松耦合,在实际的使用中来看,Import-Package能够使得面向接口的编程得以强制进行,当然,不是说require-bundle就一无是处了,^_^
      Collaboration
      在松散型的插件架构体系中,插件如何进行协作无疑是最为关注的重点, Jeff在PPT中提到了在equinox中可以采用三种方式来实现协作,分别为Extension Registry、Service Registry和Declarative Services,对Jeff把Extension Registry列在Collaboration这里我表示有些疑问,我认为Extension Registry和Collaboration关注的完全是两个层面,一个关注的是扩展,一个关注的是协作,Extension Registry不用多做介绍,在Equinox目前的版本中Declarative Service Implemention并没有列入release阶段,不过以Jeff在PPT的介绍来说非常吸引人,特别是这句"similar to Spring",^_^,不过以我对之前Osgi R4的Declarative Service的了解来说,我认为它仅仅是IoC Type1而已,但如果象Jeff所说的这样的话那Declarative Service真的非常吸引人了,之前在equinox中都是使用Service Registry的方式来实现bundles的协作,痛苦呀,^_^,等试用了Declarative Service再行评价。
      如感兴趣,可到http://eclipsezilla.eclipsecon.org/php/attachment.php?bugid=185下载此PPT。
2、Beyond Code Reuse
      这个PPT中总结了一些Eclipse带给我们超越代码复用级别的思考,总结的非常好:
      Modularize your applications
      Eclipse让我们看到了如何去模块化的设计应用系统,最重要的几点就在于定义组件和API以及管理模块间的依赖,方式在1中的PPT的Modularity中有所提及。
      Separate UI and core modules
      这点如果你阅读过《Contributing to Eclipse》就明白了,在eclipse中有个重要的设计模式,称为Adapative Interface/Class,^_^,可以合理的将Core Model Object扩展为UI Model Object而不造成污染....
       Design for extensibility
       Eclipse的扩展性没什么说的,^_^,都是通过Extension Points的方式来实现,这点在自己设计系统中也是值得学习的,保持模块的扩展性。
       Build to last
       这点可用于保证API的稳定。
       Adopt "The Eclipse Way"
       Eclipse采用的一些好的实践,如日构建、集成构建和发布构建、单元测试、每周的计划、6周为一里程碑、时刻保持release版本、从里程碑版本中得到反馈等等,记得以前好像有个专门的这样的PPT....
       如感兴趣,可到http://eclipsezilla.eclipsecon.org/php/attachment.php?bugid=123下载此PPT。
3、From Osgi R3 to Eclipse and Equinox
      对这个PPT中的一些观点非常的不认同,在这个PPT中作者首先定义了两个名词:
      BAPM: Osgi R3 Bundle Activator Programming Model
      HPM: Eclipse Extension Points & Osgi R4 Declarative Services Programming Model
      作者对这两种方式进行了一系列比较,他认为:
       BAPM
       更简单
       有工具可支持校验等
       允许使用纯pojos来实现业务逻辑处理
       更为灵活(在重构和测试方面)
       HPM
       复杂
       DS没有工具的支持
       Extension Points的概念太复杂
       将业务逻辑处理分解到Eclipse和Equinox的API中去实现
       在大型系统方面更为高效(超过1000个的插件)
       不确定的功能特性方面支持
       BAPM更为简单我表示一定程度上的认同,毕竟Declarative Service是需要配置的,但对于BAPM允许使用纯pojos来实现业务逻辑,而HPM不支持的观点我表示怀疑,在这点上如果DS象Jeff所说可以实现setter DI的话,那么不用说,HPM自然可以使用纯Pojos来实现业务逻辑,而BAPM呢,除非能够在activator中完成plugin中各个需要外部service类的初始化,否则,就没法pojo了,就象嵌入一个web action在一个plugin中,这个时候是不能在activator中去初始化这个action的,那么何来pojo呢,^_^,同样的疑问就可以被应用在作者认为的BAPM更为灵活的观点上。
       如感兴趣,可到http://eclipsezilla.eclipsecon.org/php/attachment.php?bugid=366下载此PPT。
4、Extending Eclipse's Plug-in Concept to the SOA World
      这个PPT表达了怎么样将eclipse的plugin概念调整为适应SOA体系的观点,在这个观点上,我觉得OSGI本身其实就是个很好的服务体系的架构,甚至强过SOA,不过他们各自的关注点有所不同,所以也没什么好完全去比较的。
      如感兴趣,可到http://eclipsezilla.eclipsecon.org/php/attachment.php?bugid=145下载此PPT。

^_^,以上是看了部分的PPT的一些看法,在这次EclipseCon 2006上有非常多的优秀的PPT,象OSGi™ Component Programming等等,可以到这里找自己感兴趣的PPT下载:
http://www.eclipsecon.org/2006/Sub.do?id=all 

posted on 2006-04-05 17:12 BlueDavy 阅读(3023) 评论(0)  编辑  收藏 所属分类: Java


只有注册用户登录后才能发表评论。


网站导航:
 

公告

 









feedsky
抓虾
google reader
鲜果

导航

<2006年4月>
2627282930311
2345678
9101112131415
16171819202122
23242526272829
30123456

统计

随笔分类

随笔档案

文章档案

Blogger's

搜索

最新评论

阅读排行榜

评论排行榜