平时开发过程中,经常发现一些代码的依赖调用关系搞不清楚。所以打算好好看看spring的原理。学习参考spring in action 4.
1 spring出现的最初目的
只有一个,就是简化程序员的开发工作。
没经历过EJB、Strust开发的人或许不太明白怎么就简化开发了,以为开发一直就是这么回事。特别是只在spring框架里面写业务代码的coder来说(比如我)。下面会 举例说明下。具体参见Spring的创立者Rod Johnson(不认识,我只在网上看过Java之父的照片)写的文章。
2 那么它是如何简化的呢?
spring在总结经验的基础上,主要归结了四个策略(或者说理念等)。
a 基于POJO的轻量级和最小侵入性编程;
b 基于依赖注入和面向接口实现松耦合;
c 基于切面和惯例进行声明式编程;
d 通过切面和模板减少样板式代码。
对于第一个,不很是理解,下面有三个都和DI,IoC有关系,稍微了解。为什么只是这四个?额…
上面说的是策略、理念的东西,是“道”的层面,那在“术”的层面具体都是如何实现的呢?
2.1 激发POJO的潜能,让POJO保持纯粹
相比较其他框架的早起的版本,会强迫你继承它们的类后者实现它们的接口来使用这个框架,这样就导致你的应用代码和框架绑死了(代码层面的).具体的对比案例?而spring框架里,你写的类通常是没有任何痕迹表明你使用了它(最多可能会使用到spring注解)。
举个spring里面的类的例子:
public class HelloWorld {
private String sayHello() {
return "hello world!";
}
}
和spring无任何关联(在其他框架里面也看不出来和吧。。)
这个例子太过于简单没啥睡服力?嗯 它只是个单独的类,现实生活多个对象在一起相互协作就会产生丰富的功能了。而多个类之间的关系管理就涉及到DI了。
2.2 依赖注入,让POJO关联丰富
依赖注入-DI是一种理念,核心是什么?
旧的方式是对象自己负责管理与自己有协作、关系的对象,即对象自己管理对其他对象的引用。其实这个很自然、很正常的直观逻辑。
不自己管理,那也就说把“依赖关系”剥离出来交由一个什么东西来统一负责处理?有第三方组件来创建和惯例对象的依赖关系。如何做处理它们的依赖关系?通过依赖接口来表明依赖关系,而不是实现类。 这样实现类被依赖管理了,但是它是无感知的。这话太抽象了,我们也知道解耦的关键就是面向接口编程,设计模式也是这么要求的。来个例子来理解。
如何注入呢?spring提供了三种方式。
1 是xml
2 Java config
3 自动依赖注入
先看第一个:
不面向接口:
/**
* 营救少女的骑士
*/
public class DamelRescuingKnightimplements KnightInf {
private RescueDamselQuestquest;
/**
* 构造器里面new 一个对象,this.自己管理和其他对象的管理--紧耦合在一起
*/
public DamelRescuingKnight() {
this.quest =new RescueDamselQuest();
}
//探险 只能执行RescueDamselQuest的探险,其他对象的探险不好处理
public void embarkonQuest() {
quest.embark();
}
}
面向接口:
····/**
* 骑士是一种职业,比如学生,老师,所以作为接口
* 而具体某个骑士可以是对象
*
* @see com.flynn.action1.imp.DamelRescuingKnight
*/
public interface KnightInf {
void embarkonQuest();
}····
····/**
* 勇敢的骑士
*/
public class BraveKnightimplements KnightInf {
//接口
private QuestInfquest;
public BraveKnight(QuestInf quest) {//QuestInf 接口而不再是具体实现
this.quest = quest;//不需要再 new XX实现类
}
@Override
public void embarkonQuest() {
quest.embark();
}
}····