黄晓童SPRING学习札记：对DI的初步理解

黄晓童SPRING学习笔记：对DI的初步理解

Spring的定义
对DI的初步理解
对AOP的初步理解
对DI的深入探究
对AOP的深入探究
Spring的事务管理
Spring MVC

?

?

??? 首先，我们来看这样一个场景：有一个骑士，他要去完成寻找圣杯的任务。情景很简单，我们以往的做法是这样的：声明一个骑士类，再声明一个寻找圣杯的任务类，骑士类是依赖于任务类的，代码如下：

Public class XunZhaoShengBeiRenWu{ public  ShengBei  zhiXing() {  return  new  ShengBei(); }}Public class QiShi{ private  XunZhaoShengBeiRenWu  renWu;  public QiShi () {  renWu = new XunZhaoShengBeiRenWu (); }  public  ShengBei  ZhiXingRenWu ()  { return  renWu. zhiXing (); }}

?

??? 上面的代码是没有任何问题的，不过仔细一看就会发现其中有很多设计不合理的地方。比如，骑士类和寻找圣杯的任务类耦合太紧密，这将直接导致该代码的重用性不高，并且，在做单元测试的时候也会有问题，因为每个骑士都要自己去获得寻找圣杯的任务，这就导致在测试骑士类的时候间接的测试了寻找圣杯的任务类。
?因此，问题就是模块之间耦合太高。一个很好的解耦的方法就是将具体的实现隐藏在接口下面。具体做法是：声明一个“RenWu”接口，让“XunZhaoShengBeiRenWu”来实现这个接口。

Public interface RenWu{ public  ShengBei  zhiXing() ;}

?

修改原来的“XunZhaoShengBeiRenWu”类为：

Public  class  XunZhaoShengBeiRenWu  implement  RenWu{ public  ShengBei  zhiXing() {  return  new  ShengBei(); }}

?

同时，为了与“RenWu”接口兼容，将原“QiShi”类修改为：

Public  class  QiShi  implement  RenLei{ private  RenWu  renWu;  public QiShi () {  renWu = new XunZhaoShengBeiRenWu (); }  public  ShengBei  zhiXingRenWu ()  { return  renWu. zhiXing (); }}

?

?经过这样的一番修改之后，我们的设计确实是比以前的好了许多。不过这里还有一个问题，骑士仍然是只能执行寻找圣杯的任务，如果骑士要执行一个保护圣杯的任务的话，那就要修改原来的代码了。为了解决这个问题，我们终于引入了DI。下面，我们将骑士类再次修改成如下这样：

Public  class  QiShi  implement  RenLei{ private  RenWu  renWu;  public void setRenWu (RenWu  renWu ) {  this.renwu = renWu ; }  public  ShengBei  zhiXingRenWu ()  { return  renWu. zhiXing (); }}

?

?看了上面的修改你会发现，这时的骑士不是自己主动的获得寻找圣杯的任务了，而是被动的通过set方法被注入进来。这时，如果骑士要执行保护圣杯的任务，我们只要定义一个实现了“任务”接口的“保护圣杯任务”的类，并将该类的实例通过set方法注入即可。
?在spring中，我们是通过xml配置文件来实现对骑士类进行注入的，具体的细节后面会提到，配置文件如下：

<beans> <bean id="renWu" ref="renWu" /> </bean></beans>

?

在Main方法中，装载该bean的方法如下：

ApplicationContext ctx = new ClassPathXmlApplicationContext("com/alibaba/qishi.xml");QiShi qiShi = (QiShi) ctx.getBean("qiShi");qiShi.zhiXingRenWu();

?