网站内容批量替换,php网站源码免费下载,django网站开发实例,wordpress评论楼2019独角兽企业重金招聘Python工程师标准 Inversion of Control#xff0c;即反转控制#xff0c;或许说为依赖注入更为合适。IoC就是一种设计模式。 Interface Driven Design接口驱动#xff0c;接口驱动有很多好处#xff0c;可以提供不同灵活的子类实现 Inversion of Control即反转控制或许说为依赖注入更为合适。IoC就是一种设计模式。 Interface Driven Design接口驱动接口驱动有很多好处可以提供不同灵活的子类实现增加代码稳定和健壮性等等但是接口一定是需要实现的也就是如下语句迟早要执行AInterface a new AInterfaceImp(); 这样一来耦合关系就产生了如 Class A{ AInterface a; A(){} aMethod(){ a new AInterfaceImp(); } }ClassA与AInterfaceImp就是依赖关系如果想使用AInterface的另外一个实现就需要更改代码了。当然我们可以建立一个Factory来根据条件生成想要的AInterface的具体实现即 InterfaceImplFactory{ AInterface create(Object condition){ if(condition condA){ return new AInterfaceImpA(); }elseif(condition condB){ return new AInterfaceImpB(); }else{ return new AInterfaceImp(); } } } 通过IoC模式可以彻底解决代码耦合它把耦合从代码中移出去放到统一的XML文件中通过一个容器在需要的时候把这个依赖关系形成即把需要的接口实现注入到需要它的类中这可能就是“依赖注入”说法的来源了。 IOC模式系统中通过引入实现了IOC模式的IOC容器即可由IOC容器来管理对象的生命周期、依赖关系等从而使得应用程序的配置和依赖性规范与实际的应用程序代码分开。其中一个特点就是通过文本的配件文件进行应用程序组件间相互关系的配置而不用重新修改并编译具体的代码。 当前比较知名的IOC容器有Pico Container、Avalon 、Spring、JBoss、HiveMind、EJB等。 在上面的几个IOC容器中轻量级的有Pico Container、Avalon、Spring、HiveMind等超重量级的有EJB而半轻半重的有容器有JBossJdon等。 可以把IoC模式看做是工厂模式的升华可以把IoC看作是一个大工厂只不过这个大工厂里要生成的对象都是在XML文件中给出定义的然后利用Java 的“反射”编程根据XML中给出的类名生成相应的对象。从实现来看IoC是把以前在工厂方法里写死的对象生成代码改变为由XML文件来定义也就是把工厂和对象生成这两者独立分隔开来目的就是提高灵活性和可维护性。 IoC中最基本的Java技术就是“反射”编程。反射又是一个生涩的名词通俗的说反射就是根据给出的类名字符串来生成对象。这种编程方式可以让对象在生成时才决定要生成哪一种对象。反射的应用是很广泛的象Hibernate、String中都是用“反射”做为最基本的技术手段。 在过去反射编程方式相对于正常的对象生成方式要慢10几倍这也许也是当时为什么反射技术没有普通应用开来的原因。但经SUN改良优化后反射方式生成对象和通常对象生成方式速度已经相差不大了但依然有一倍以上的差距。 IoC最大的好处是什么因为把对象生成放在了XML里定义所以当我们需要换一个实现子类将会变成很简单一般这样的对象都是现实于某种接口的只要修改XML就可以了这样我们甚至可以实现对象的热插拨有点象USB接口和SCIS硬盘了。 IoC最大的缺点是什么 1生成一个对象的步骤变复杂了其实上操作上还是挺简单的对于不习惯这种方式的人会觉得有些别扭和不 直观。 2对象生成因为是使用反射编程在效率上有些损耗。但相对于IoC提高的维护性和灵活性来说这点损耗是微不足道的除非某对象的生成对效率要求特别高。 3缺少IDE重构操作的支持如果在Eclipse要对类改名那么你还需要去XML文件里手工去改了这似乎是所有XML方式的缺憾所在。IOC实现初探 IOC关注服务(或应用程序部件)是如何定义的以及他们应该如何定位他们依赖的其它服务。通常通过一个容器或定位框架来获得定义和定位的分离容器或定位框架负责 ?保存可用服务的集合?提供一种方式将各种部件与它们依赖的服务绑定在一起?为应用程序代码提供一种方式来请求已配置的对象(例如一个所有依赖都满足的对象)这种方式可以确保该对象需要的所有相关的服务都可用。现有的框架实际上使用以下三种基本技术的框架执行服务和部件间的绑定: ?类型1 (基于接口): 可服务的对象需要实现一个专门的接口该接口提供了一个对象可以从用这个对象查找依赖(其它服务)。早期的容器Excalibur使用这种模式。?类型2 (基于setter): 通过JavaBean的属性(setter方法)为可服务对象指定服务。HiveMind和Spring采用这种方式。?类型3 (基于构造函数): 通过构造函数的参数为可服务对象指定服务。PicoContainer只使用这种方式。HiveMind和Spring也使用这种方式。IoC就是Inversion of Control控制反转。在Java开发中IoC意味着将你设计好的类交给系统去控制而不是在你的类内部控制。这称为控制反转。 下面我们以几个例子来说明什么是IoC 假设我们要设计一个Girl和一个Boy类其中Girl有kiss方法即Girl想要Kiss一个Boy。那么我们的问题是Girl如何能够认识这个Boy 在我们中国常见的MM与GG的认识方式有以下几种1 青梅竹马 2 亲友介绍 3 父母包办那么哪一种才是最好呢 青梅竹马Girl从小就知道自己的Boy。 public class Girl {void kiss(){Boy boy new Boy();}} 然而从开始就创建的Boy缺点就是无法在更换。并且要负责Boy的整个生命周期。如果我们的Girl想要换一个怎么办严重不支持Girl经常更换Boy,#_# 亲友介绍由中间人负责提供Boy来见面 public class Girl {void kiss(){Boy boy BoyFactory.createBoy();}} 亲友介绍固然是好。如果不满意尽管另外换一个好了。但是亲友BoyFactory经常是以Singleton的形式出现不然就是存在于 Globals无处不在无处不能。实在是太繁琐了一点不够灵活。我为什么一定要这个亲友掺和进来呢为什么一定要付给她介绍费呢万一最好的朋友爱上了我的男朋友呢 父母包办一切交给父母自己不用费吹灰之力只需要等着Kiss就好了。 public class Girl {void kiss(Boy boy){// kiss boyboy.kiss();}} Well这是对Girl最好的方法只要想办法贿赂了Girl的父母并把Boy交给他。那么我们就可以轻松的和Girl来Kiss了。看来几千年传统的父母之命还真是有用哦。至少Boy和Girl不用自己瞎忙乎了。 这就是IOC将对象的创建和获取提取到外部。由外部容器提供需要的组件。 我们知道好莱坞原则“Do not call us, we will call you.” 意思就是You, girlie, do not call the boy. We will feed you a boy。 我们还应该知道依赖倒转原则即 Dependence Inversion PrincinpleDIP Eric Gamma说要面向抽象编程。面向接口编程是面向对象的核心。 组件应该分为两部分即 Service, 所提供功能的声明 Implementation, Service的实现 好处是多实现可以任意切换防止 “everything depends on everything” 问题即具体依赖于具体。 所以我们的Boy应该是实现Kissable接口。这样一旦Girl不想kiss可恶的Boy的话还可以kiss可爱的kitten和慈祥的grandmother。二、IOC的type IoC的Type指的是Girl得到Boy的几种不同方式。我们逐一来说明。 IOC type 0不用IOCpublic class Girl implements Servicable {private Kissable kissable;public Girl() {kissable new Boy();}public void kissYourKissable() {kissable.kiss();}} Girl自己建立自己的Boy很难更换很难共享给别人只能单独使用并负责完全的生命周期。 IOC type 1先看代码代码 public class Girl implements Servicable { Kissable kissable; public void service(ServiceManager mgr) {kissable (Kissable) mgr.lookup(“kissable”);} public void kissYourKissable() {kissable.kiss();} } 这种情况出现于Avalon Framework。一个组件实现了Servicable接口就必须实现service方法并传入一个ServiceManager。其中会含有需要的其它组件。只需要在service方法中初始化需要的Boy。 另外J2EE中从Context取得对象也属于type 1。它依赖于配置文件。 IOC type 2 public class Girl { private Kissable kissable; public void setKissable(Kissable kissable) {this.kissable kissable;} public void kissYourKissable() {kissable.kiss();} } Type 2出现于Spring Framework是通过JavaBean的set方法来将需要的Boy传递给Girl。它必须依赖于配置文件。 IOC type 3: public class Girl { private Kissable kissable; public Girl(Kissable kissable) {this.kissable kissable;} public void kissYourKissable() {kissable.kiss();} } 这就是PicoContainer的组件 。通过构造函数传递Boy给Girl PicoContainer container new DefaultPicoContainer();container.registerComponentImplementation(Boy.class);container.registerComponentImplementation(Girl.class);Girl girl (Girl) container.getComponentInstance(Girl.class);girl.kissYourKissable(); 参考资料 1 http://www.picocontainer.org/presentations/JavaPolis2003.ppthttp://www.picocontainer.org/presentations/JavaPolis2003.pdf 2 DIP Robert C Martin, Bob大叔的优秀论文http://www.objectmentor.com/resources/articles/dip.pdf 3 Dependency Injection 依赖注射Matrin Fowler对DIP的扩展http://www.martinfowler.com/articles/injection.html 4 IOC框架 PicoContainer 优秀的IOC框架http://picocontainer.org/ Avalonhttp://avalon.apache.org/ Spring Frameworkhttp://www.springframework.org/ HiveMindhttp://jakarta.apache.org/commons/hivemind 转载于:https://my.oschina.net/u/1462795/blog/272056
