是否能够真正做面向接口的开发，和系统所采用的容器或框架具有很大的关系，面向接口的开发最重要的就是解决系统的依赖问题，在这点上目前最成熟的解决方案莫过于IoC，IoC容器而言最成功的莫过于Spring，那么基于OSGI的话是不是会带来不同的视角呢，来看看这几个方面的例子：
1、A类希望能够执行系统中实现了B接口的类
在OSGI中实现这种是多么的简单，可以看看：
ServiceReference[] serviceRefs=context.getServiceReference(B.class.getName());
for(int i=0;i<serviceRefs.length;i++){
B b=(B)context.getService(serviceRefs[i]);
b.execute();
}
用习惯了IoC的人都会去说上面的方法还需要通过context主动获取这么的烂，那么在OSGI中你同样可以用下面的这样一种方式去调用：
public void setService(B b){
b.execute();
}
这样的方式满意了吧，在这样的情况只需要将这个类对于B的引用配置为cardinality="0..n"，那么OSGI框架就会自动的去完成调用实现了B接口的类的execute方法。
ps: 可以想象基于这样的方式要实现COR Pattern是多么的容易....
2、A类引用了Log接口，但无所谓系统中有否Log接口的实现此类都需要正常运行
在OSGI中要做到这个同样是非常的容易：
public void setLog(Log log){
this.log=log;
}
只需要将这个类对于Log的引用配置为：cardinality="0..1"
3、A类希望根据某种条件来决定到底调用哪个实现接口的类
在OSGI中可以通过象属性过滤、版本过滤等多种方式来动态的决定调用相应的实现接口的类，可以想象有这种来实现类似的业务逻辑的处理是不是更加的简单和方便呢。
4、动态性
这个自然是因为OSGI 带来的特性，在基于OSGI构建的这样的系统中，我们完全可以先定义好接口，然后启动整个系统，当完成了某个接口的实现后，部署到OSGI框架中，再使用此接口的功能后自然就可以直接使用了，整个系统完全无需进行重启等麻烦的操作。
从以上简单的几个例子可以看出，基于OSGI做真正的面向接口的开发变得非常的容易和灵活，而动态性特征更是使得可以完全以接口的方式先搭建好系统，这对于迭代式的开发模型来说非常的重要。
为什么说这样的方式才是真正的面向接口的开发呢，可以看到在传统的开发方式中，无论怎么样，都仍然是要先有实现了接口的类后系统才可运行，而在基于OSGI的开发中完全不需要，在基于OSGI的系统中开发人员可以确定当需要的接口的实现都提供了后，功能自然就是实现了的，而无需管系统中是否具体有接口的实现，更为重要的一点是由于传统的开发方式多是在运行前定义好依赖关系，而在基于OSGI的系统很容易实现运行期才决定依赖关系，这对于提升系统的灵活性的效果不言而喻。
ps：我知道很多spring高手在看了上面的例子后会告诉我基于spring也可以去实现上面的这些例子，但是不是要做出更多的增强呢，spring本身并没有classloader的完整机制，所以要基于它去实现这些动态的特征的时候会变得很复杂，而既然现在OSGI已经提供了这些，为什么一定要基于spring去增强来达到这些已经在OSGI中达到的目标呢？