对IOC于DI的一些理解

原文链接:http://www.cnblogs.com/xdp-gacl/p/4249939.html

专业解释:http://blog.csdn.net/ddkii/article/details/79488327(本文为个人不正经理解)

一 IOC(控制反转)和DI并不是两种技术,而是两种思想,或者说是对同一概念的两种表述

在此之前我们需要知道传统编程中程序是如何完成任务的:

传统编程中,程序在完成一套业务,需要两个东西,一个是流程(逻辑),第二是执行对象(资源).执行对象(资源)是程序自己安排的(程序需要自己new 实例).

在这里,有几个事实是很清楚的:程序和资源是高度联系的,程序控制资源,程序具有支配一切的主动权.

当引入IOC容器之后问题发生了变化,IOC直接剥离了程序和资源的联系,并由自己掌控资源,程序再也无法自己控制资源,程序想要资源的时候必须向IOC容器申请.

在这里,我们发现了明显的变化:出现了一个第三方(IOC),程序除了对资源的使用权,其他权利都失去了.

那么,失去了大部分权利的程序本身还剩下什么?只剩下了流程(业务逻辑).这就是spring的目的.是开发本身专注于业务逻辑,不为其他的事务烦劳

二 这有什么好处,或者说传统开发中有什么弊端?

开发中的弊端:

1) 程序有无限制的权力去获取对象,也就是如果编写程序的程序员不具备控制这些权力的能力时,这样的权力就极有可能被滥用.表现在程序本身就,就是程序依赖的对象冗余,耦合度高,对象见关系错综复杂.而在实际开发中,程序员不具备这样的能力是常态—或者说大多数公司会为了开发效率而牺牲性能.

2) 权利与义务的统一.在传统编程中,程序拥有无限制的权利,而这就意味着程序也必须对他创造的对象负责.例如,IO和Connection需要我们自己手动去关闭.

3) 封闭的生态环境造成可维护性极差,传统编程中.因为创造对象的权力在自己手里,程序是可以完全独立运行的.但也正因为这样.他的可扩展性极差.我们要修改程序,就必须到程序内部找到完成逻辑的对象,然后进行更改

IOC完美解决了这些问题

1) IOC限制了程序本身获取对象的权利,程序要使用对象需要等待IOC容器注入.这样IOC容器可以管理对象之间的关系,减少了程序的随意性

2) IOC容器也管理对象的生命周期.程序需要一个对象的时候,用就可以了,完全可以不去理用完之后该怎么处理.

3) IOC使程序变得开放.打个比方,有了IOC之后,程序本身就相当于了一套模板,我们放入不同的对象就有不同的结果.需要维护的时候也再也不用剖开程序区修改里面的东西.改IOC注入的东西就可以了

总结就是:

IOC就是程序的老婆,结婚后老婆管钱了,再也不能为所欲为了.狐朋狗友也被老婆赶跑了.但好处就是,内衣内裤臭袜子可以不用自己洗了,房间有人打扫了,有人做饭了.自己只需要安心工作就行了