OSGi与依赖倒转原则

前端之家收集整理的这篇文章主要介绍了OSGi与依赖倒转原则前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

依赖倒转原则是指导设计两个模块之间的关系的一个设计原则。如下图所示,假设模块A是我们系统要实现的核心功能,模块B提供某种事务服务。因为模块A需要事务服务,所以,一般的设计思想是模块A要依赖于模块B

依赖倒转原则就是要把这种依赖关系倒转过来。也就是让模块B依赖于模块A

样,模块A代码实现中,涉及事务的地方,只需要使用接口A,而接口A的实现是在运行时被依赖注入到模块A的程序中去的。这样保证了,模块A是面向接口进行编程的,从而使得事务服务可被替换;同时保证了模块A真正专注于核心功能的实现。因此,依赖倒转的实现总是伴随着依赖注入。

当不使用OSGi时,我们照样可以实现依赖倒转的设计思想,但是当系统复杂时,很难从程序上判断真正的依赖关系是否是这样的,至少在编译环境下,我们看不出来。而使用OSGi解决了这样一个问题。当我们设计模块B依赖于模块A时,模块A是看不到模块B的任何类的,因此在编译时,就保证了模块A不依赖于模块B

Spring框架也是基于依赖注入的,但是,OSGi的依赖注入与Spring有明显的不同。

Spring的注入点与被注入对象是通过beanid进行严格匹配的,如下所示:

<beans>

<bean id="component1"

class="org.shuyaji.examples.Component1" singleton="false"/>

<bean id="component2"

class=" org.shuyaji.examples.Component2" singleton="false">

<constructor-arg><ref bean="component1"/></constructor-arg>

</bean>

</beans>

Component2声明为要被注入Component1,是通过ref标签显式定义的。

OSGi由于是完全动态的,一个要被注入其它对象的Component,只需要公开声明其所依赖的接口,而实现此接口的对象,则会在运行时动态查找并自动的注入。如果此接口有多个实现Component,则到底被注入是哪一个?如何确定?这个问题目前我也比较疑惑,毕竟有些情况下我们还是需要能决定OSGi到底采用哪个Service的。可能采用过滤器匹配能实现吧。

<component name="component1">

<implementation class="org.shuyaji.examples.Component1"/>

<service>

<provide interface="org.shuyaji.examples.CompInterface"/>

</service>

</component>

<component name="component2">

<implementation class="org.shuyaji.examples.Component2"/>

<reference name="compInterface"

interface="org.shuyaji.examples.CompInterface"

bind="setCompInterface" policy="dynamic"/>

</component>

估计这也是OSGi为什么没有“构造函数”注入方式的原因。因为,被注入的对象是在运行时动态匹配和注入的,也就是说在时刻aComponentA可能被注入了CompomentB,但是一段时间后,在时刻bComponentB所在的Bundle可能被停止了,取而代之的是ComponentC,那么这时,ComponentA(注意仍然是原来的对象实例,而非重新new出来的A)被注入的就是ComponentC了。这样,注入的方式只能是通过set方式了。

而在Spring中,存在构造函数注入方式说明了Spring的容器在初始化Bean时就把Bean所需要的都准备好了,而且不可能进行动态的调整。

原文链接:https://www.f2er.com/javaschema/288267.html

猜你在找的设计模式相关文章