IoC & Extension Point

昨天在fog讨论到这个问题,fog认为Extension Point是按照IoC的思路实现出来的,我来谈谈我的观点,我却认为Extension Point并不是按照IoC思路来实现的,甚至可以说两者没有关系。
首先来说说IoC,IoC,全称Inversion of Control,Martin Fowler认为这个词有些不恰当,建议改为DI,为什么呢?其实这是因为IoC的本质决定的,IoC是什么,其主要作用是解耦,分离关注点,通俗点说就是使得调用者和被调用者之间没有直接的耦合,而只是接口的耦合,举例来说:

在没用IoC实现的时候是这样的:

public class A{
 
 
public void execute(){
  B b
=new BImpl();
  b.execute();
 }


}


可见在这里造成的一个问题就是调用者A和被调用者B的实现构成了一个直接的依赖,为什么Martin Fowler要建议改名成DI呢,原因就在这了,这里造成的是抽象对实现的依赖,这不用说,是严重违反OO中依赖抽象而不依赖实现这一原则的,所以称为DI确实更符合一些。

再来看一下使用了IoC后是这样的:

public class A{
 
 
private B b;

 
public void setB(B b){
  
this.b=b;  
 }


 
public void execute(){
  b.execute();
 }
 

}


可见在这里调用者A和被调用者B是接口的依赖,而不是实现的依赖,这就实现了调用者对于被调用者具体实现依赖的解耦。
当然,也许诸位看官会说可以用Factory之类的模式来实现对具体依赖的解耦,但那样同样造成一个问题就是调用者和被调用者的Factory耦合,而在IoC中是不会有这个问题的,调用者和被调用者之间只有清晰的接口依赖。
根据上面这些解释,我们可以看出IoC最大的好处在于解耦调用者对于被调用者具体实现的依赖。

现在来说说Extension Point,Extension Point是Eclipse为支持Plugin扩展而做的一种设计,举例来说吧,在工具栏这个Plugin中,必然需要提供某种方法能使得其他Plugin可加入按钮至工具栏中,那么该怎么去做呢,在Extension Point中是这么实现的,工具栏Plugin提供了一个这样的Extension Point,其他的Plugin只需要实现这个Extension Point即可加入按钮至工具栏中,工具栏的Plugin在可扩展的地方通过对于容器中Extension Point注册信息的获取来取得所有实现了当前Extension Point的类,并相应的进行调用。
这里还是得罗嗦一下Extension Point的实现思路,在Eclipse中是这么做的,首先它会根据各Plugin提供的Extension Point构成一个Extension Point的信息集合,之后根据各Plugin提供的Extension Point的实现构成Extension Point Registry,而各提供了Extension Point的Plugin必然会在可扩展的地方调用这个Registry获取相应实现了此Extension Point的集合,通过所提供的Extension Point Interface做相应的callback来实现扩展。
首先我们来看,如果Extension Point是采用IoC思想来实现的,那么我们可以按照IoC思想来进行分析,那么提供Extension Point的Plugin就是调用者,提供Extension Point实现的Plugin就是被调用者,按照IoC思想是为了解耦调用者对于被调用者实现的依赖,那么我们可以看出这个命题是不成立的,这里的关键在于提供Extension Point的Plugin并不依赖于实现Extension Point的Plugin,它才不关心哪些Plugin实现了它的Extension Point,没有直接的依赖关系又何来IoC一说。
其次我们来看Extension Point的设计目的是为了什么?它设计的目的是为了Plugin可被扩展,而不是说用于解除Plugin之间依赖的问题。
其实Extension Point的设计思路很简单,是类似Template的模式,只是它把所有实现了此Template的信息都集中存储了,并且由提供了Template的类去获取了所有的这些信息,鉴于此我还是坚持自己的观点Extension Point并不是按照IoC的思想来设计的,两者并没什么关系。

posted on 2005-07-15 10:47 BlueDavy 阅读(852) 评论(2)  编辑  收藏 所属分类: Java

评论

# re: IoC & Extension Point 2005-07-16 00:09 落魄的程序员

我认同fog的观点
而且DI和Template模式正是IoC在面向对象领域的表现形式
DI和模板方法模式的区别在于
DI用于解除创建依赖
模板方法用于解除行为依赖

你的这几句似乎有逻辑问题:
“我们可以按照IoC思想来进行分析,那么提供Extension Point的Plugin就是调用者,提供Extension Point实现的Plugin就是被调用者,按照IoC思想是为了解耦调用者对于被调用者实现的依赖,那么我们可以看出这个命题是不成立的,这里的关键在于提供Extension Point的Plugin并不依赖于实现Extension Point的Plugin”

真是因为EP的提供者不依赖于EP的实现者,所以才符合IoC的思想
也就是组件IoC
而不是因为EP中没有IoC要解耦的那种依赖所以不叫IoC

因为它符合IoC,所以不存在IoC要解决的问题,这个是不是有点绕?
^_^
因为符合IoC,所以问题已经被解决掉了,自然不存在了
  回复  更多评论   

# re: IoC & Extension Point 2005-07-16 17:34 Programmer's Life

恩,说的是,那个逻辑分析我写的是有问题的,应该从EP解决的问题点来分析  回复  更多评论   


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


网站导航:
 

公告

 









feedsky
抓虾
google reader
鲜果

导航

<2005年7月>
262728293012
3456789
10111213141516
17181920212223
24252627282930
31123456

统计

随笔分类

随笔档案

文章档案

Blogger's

搜索

最新评论

阅读排行榜

评论排行榜