这两天学习设计模式,看到了关于依赖反转方面的东西,就依赖反转而言简单来说就是:软软设计存在抽象层和实现层之分,一般情况下是抽象依赖于实现,这很容易理解,但是问题在于抽象层相对稳定,实现层容易变化,抽象层应该具有较实现层更高的复用性,它就应该我们设计和考量的核心与重点,而不是具体的实现,这样一来,要求我将依赖关系反转过来,即实现应该依赖于我们的抽象,这样的设计才是灵活和易于扩展的。如此一来,依赖反转的概念就出来了,但是如果实现依赖反转呢?答案听上去是很简单的那就是基于接口进行编程,关于这一点在许多讲述设计模式的书中都有所介绍,接口是对类和方法的一组需求定义,由于接口不提供任何实现,它是一种最纯的抽象,基于接口进行编程可以真正意义上实现在抽象层上进行工作。但是还有一个恼人的小问题:
interface IService
{
public void doSomething();
}
class ServiceImpl implements IService
{
public void doSomething()
{
// do something......
}
}
class Component
{
private IService service=new ServiceImpl(); //这里是基于接口进行编程,但却在构造时与具体的实现发生了耦合
//后继方法中会使用该service
}
问题就出在对service的实例化上,我们可以明确的看到接口service在实例化时要不可避免地使用到它的实现类,从而导致了 service至少在创建时刻对具体实现产生了依赖,这使得我们之前打算的基于接口进行编程的工作似乎功亏一篑。在一些设计模式的书中对于这一问题的解决方法是使用工厂模式,来实现对service实例化的封装。
呵呵,写到这里禁不住要偷笑了,因为晚上在思考这个问题的时候实然想到了spring的依赖注入,不禁恍然大悟:不需使用什么工厂模式,运用spring的依赖注入会完美地解决“抽象在创建时刻对实现产生依赖”的问题,在我们代码里,抽象将永远不需要再被指向他的具体实现了,这个过程会放到sping 的配制文件里,使用依赖注入的方式完成,这样了,我们真得就可以完美使用接口进行编程了!
以下内容是2010-5-8的补充:
在我刚开始接触spring和IOC理论时,最常见的IOC示例就是Service依赖DAO时,在Service的实现类里声明一个DAO字段,通常这个DAO是一个接口,然后提供一个setter,就在Service的方法中开始使用这个DAO了,整个Service没有实例化这个DAO的操作。其实这个示例展示了两点:一个是依赖注入,另一个是基于抽象编程。我当时一直认为:只有在基于抽象编程的前提下,进行依赖注入才是有意义的。否则声明的是一个具体类,再注入一个具体类有什么意义呢?这是我三年前对IOC的认识。
后来,我研究一个IOC框架PicoContainer:http://www.picocontainer.org/,这个IOC构架的参考文档让我对IOC有了更进一步的认识,也使我发现了我过去对IOC认识的一个局限。本质上讲,IOC之所以如此重要,是因为它解决了OO技术中一个重要的缺失:如何合理地创建对象并将它们关联起来协同工作。面向对象技术注重于对对象属性与行为的模拟,对这些对象从何而来,怎样相互依赖缺乏合理的模拟机制。很多时候,当一个对象A依赖到另一个对象B时,我们就new一个B的实例出来。这样做在有些时候是合理的,有些时候就是不恰当的。上面提及的基于抽象编程时就是一种情况。还有其他的情况。比如:A有没有创建B的责任?如果A没有创建B的责任,那么就不应该让A来承担。这是OO设计的一个重要原则:Designing Objects with Responsibilities。关于这一点,《Applying UML and Patterns, 3rd Edition》一书17.10节有详尽的说明。
总之IOC就像一个系统的对象容器和粘合剂,它负责创建对象的实例,并按照它们声明的依赖关系把它们粘合起来共同工作。
分享到:
相关推荐
控制反转 依赖注入的c#实现,很好的教程。
依赖倒置 控制反转 依赖注入 面向
spring 控制反转和依赖注入进行基础知识的生命周期、延迟初始化、装配方式等进行案例总结使用。从而对spring基础知识更加理解。
Spring 控制反转和依赖注入
简单的c#中的三层架构及依赖反转的运用,一个图书馆里系统的简单模型。
NULL 博文链接:https://slnddd.iteye.com/blog/1756411
springIOC 小例子 附带源码 适合新手学习
javaEE 开发中 现在最成熟的框架之一应该就是spring了 spring框架最强大的地方就是实现了依赖注入 也叫控制反转 最近的一个项目中用的就是 spring框架 spring框架是工厂模式的应用结合了MVC的设计思想 大家可以...
1.2 IoC(控制反转)和DI(依赖注入)入门 1 传统的Java类 在工程下创建包ioc,在ioc包中创建类Test。(为了看起来清楚,将三个类写在了同一个Java文件中,其中唯一的public类为Test)。类的含义和关系如下: Car类...
比如,下面这几个问题,你看看能否清晰地回答出来:“依赖反转”这个概念指的是“谁跟谁”的“什么依赖”被反转了?控制反转(IOC)在讲“依赖反转原则”之前,我们先讲
在本文中,我将深入探索这个模式的工作原理,给它一个更能描述其特点的名字——“依赖注入”(Dependency Injection),并将其与“服务定位器”(Service Locator)模式作一个比较。不过,这两者之间的差异并不太...
spring的控制反转和依赖注入详解
解析控制反转和依赖注入的原理,帮助初学者进一步学习!
此文档仅供初学者学习,包括Spring的依赖注入(控制反转)的详细实例。以三层贯穿实例(持久层、业务层、控制层),由MAIN方法直接调用测试用例。
【IOC 控制反转】Android 视图依赖注入 ( 视图依赖注入步骤 | 视图依赖注入代码示例 ) https://hanshuliang.blog.csdn.net/article/details/120404805 博客源码快照
【IOC 控制反转】Android 布局依赖注入 ( 布局依赖注入步骤 | 布局依赖注入代码示例 ) https://hanshuliang.blog.csdn.net/article/details/120402953 博客源码快照
要想理解php依赖注入和控制反转两个概念,就必须搞清楚如下的问题: DI——Dependency Injection 依赖注入 IoC——Inversion of Control 控制反转 1、参与者都有谁? 答:一般有三方参与者,一个是某个对象;...
控制反转IOC(Inversion of Control)是一种设计思想,DI(依赖注入)是实现IOC的一种方法 。在没有IOC的程序中,我们使用面向对象编程,对象的创建于对象间的依赖完全硬编码在程序中,对象的创建有程序自己控制;...
“控制反转(Inversion of Control)的一个著名的同义原则是由Robert C. Martin提出的依赖倒置原则(Dependency Inversion Principle),它的另一个昵称是好莱坞原则(Hollywood Principle:不要调用我,让我来调用...
依赖注入又称之为控制反转(Inversion of Control,英文缩写为IoC)是一个重要的面向对象编程的法则来削减计算机程序的耦合问题,也是轻量级的Spring框架的核心。 控制反转一般分为两种类型,依赖注入(Dependency ...