关于Spring-IOC的理解
Ioc—Inversion of Control,即“控制反转”,它并不是一种技术,而是一种设计思想。通过IOC,可以降低计算机代码之间的耦合度。光用语言来说难以理解,我们就通过代码的方式来引入控制反转的思想吧。
传统的JavaSE程序设计
我们以课程为例,CourseDao接口代码如下:
public interface CourseDao {
String getCourse();
}
CourseDao接口实现类JavaCourseDaoimpl代码如下:
public class JavaCourseDaoimpl implements CourseDao {
@Override
public String getCourse() {
return "Java Course";
}
}
业务层CourseService接口代码如下:
public interface CourseService {
void getCourse();
}
CourseService接口实现类CourseServiceimpl代码如下:
public class CourseServiceimpl implements CourseService {
private CourseDao courseDao = new JavaCourseDaoimpl();
@Override
public void getCourse() {
System.out.println(courseDao.getCourse());
}
}
这是一个非常传统的设计模式,将CourseDao接口的实现类作为CourseServiceimpl的成员变量,从而CourseServiceimpl可以调用CourseDao的方法。但是,如果我增设了Python课程,按照这个设计模式,我要增加一个类,PythonCourseDaoimpl类的代码如下:
public class PythonCourseDaoimpl implements CourseDao {
@Override
public String getCourse() {
return "Python Course";
}
}
当我的主程序想要获取到Python的课程时,我们就不得不把CourseServiceimpl中的JavaCourseDaoimpl修改为PythonCourseDaoimpl,这显然是不符合规则的,不仅对程序造成了风险,还给程序员带来的巨大的压力。
那么该如何解决呢?
我们不妨停下来思考一下,当前依赖对象创建的主动权是在程序员的手中,用户想获取到什么,主动权并不在用户手中。从这就可以看出,这样的设计显然是不合道理的,我们应该把这主动权交给用户,所以这样修改代码。
修改后的CourseServiceimpl代码如下:
public class CourseServiceimpl implements CourseService {
private CourseDao courseDao;
public void setCourseDao(CourseDao courseDao) {
this.courseDao = courseDao;
}
@Override
public void getCourse() {
System.out.println(courseDao.getCourse());
}
}
编写测试程序:
@Test
public void test(){
CourseService service = new CourseServiceimpl();
((CourseServiceimpl)service).setCourseDao(new PythonCourseDaoimpl());
service.getCourse();
}
可以看出,在之前的程序中,程序是主动创建对象,控制权在程序员手中。在使用了set注入之后,程序不再具有主动性,而是变成了被动的接受对象。这种思想就从本质上解决了问题,程序员不需要去管理对象的创建了,把主动权交给了用户,这样就可以更加地专注于业务实现了。这种思想,就是IOC思想的前身。
在没有IOC的程序中,我们使用面向对象编程,对象的创建与对象间的依赖关系完全硬编码在程序中,对象的创建由程序自己控制。那么在有了IOC后,我们的程序又将有什么变化呢?
控制反转思想
理解好Ioc的关键是要明确“谁控制谁,控制什么,哪些方面反转了?”
在上面已经分析过,传统Java SE程序设计,我们直接在对象内部通过new进行创建对象,是程序主动去创建依赖对象。而IoC是有专门一个容器来创建这些对象,即由Ioc容器来控制对象的创建。那么谁控制谁就一目了然,当然是IOC容器获得了控制权。
那什么是反转呢?传统程序中,是我们自己主动控制去获取依赖对象。而有了IOC容器,就发生了“角色反转”,由容器来帮我们创建及注入依赖对象。
就拿食品商举例,没有IOC时,我需要自己制作与包装,整个过程十分繁琐。那么有了IOC会有什么变化呢,食品商就可以把配方与包装封面交给制作商,整个过程不再需要自己的控制,我们只需要提供配方,最后拿货就行了。。Spring所倡导的开发方式就是如此,所有的类都会在spring容器中登记,告诉spring你是个什么东西,你需要什么东西,然后spring会在系统运行到适当的时候,把你要的东西主动给你,同时也把你交给其他需要你的东西。所有的类的创建、销毁都由 spring来控制,也就是说控制对象生存周期的不再是引用它的对象,而是spring。对于某个具体的对象而言,以前是它控制其他对象,现在是所有对象都被spring控制,所以这叫控制反转。
小结
Spring是一个庞大的生态,它的诞生大大简化了开发的复杂度。Spring可以做很多事,但是我觉得,支撑它的不完全是技术,而是许多个像IOC这样的思想。因此我认为,在学习Spring及其生态时,先要明确其思想,再去研究运行时序等问题。对于这些思想而言,我相信每个人都会有自己的理解。这种概念上的东西从来都没有绝对的答案,思想的高度也没有绝对的封顶,希望大家一直向前走,或许有一天,比Spring更惊艳的框架会在中国出现。