Spring IoC and AOP

Spring IoC and AOP:

一、Spring IoC ：
1.栗子：
B{
A a = new Aimpl();
//其他代码
}
B{
private A a;
//其他代码
public void setA(A a){
this.a = a;
}
}
第一个是直接合成使用A
第二个是用控制反转进行管理
要了解控制反转，必须先了解依赖倒置原则。
举个造汽车栗子：汽车依赖车身，车身依赖地盘，地盘依赖轮子，如图：

这种设计思路完全没有问题，但是可维护性低，灵活度不够。如果领导需要改变轮子大小，因为底盘是根据轮子来设计的，所以底盘也要改，车身是根据底盘设计的，所以车身也要改…牵一发而动全身，导致几乎整个设计都要改！

如果采用第二种，控制反转思路。依赖关系就倒置过来了：轮子依赖底盘，底盘依赖车身，车身依赖汽车。

这样领导要改动轮胎，那么只需改动轮胎就可，其他都可不动。
依赖倒置原则——把原本的高层建筑依赖底层建筑“倒置”过来，变成底层建筑依赖高层建筑。高层建筑决定需要什么，底层去实现这样的需求，但是高层并不用管底层是怎么实现的。

控制反转是依赖倒置原则的一种代码设计的思路。具体的实现方法是依赖注入。
依赖注入有3种方式：

• 构造函数注入
• 接口注入
• setter 注入
  依赖注入容易产生大量不可避免的new 。为了解决这个问题，于是IOC容器诞生了。将原先散落在各处的new对象，统一放在Ioc容器管理，即Configuration。这个容器可以自动对我们的代码进行初始化，只需要维护Configuration（可以是xml，可以使一段代码），而不用每次初始化写一大堆初始化代码。
  这是引入Ioc 容器的一大好处，另一好处是：在创建实例的时候不需要了解其中的细节。
  在上面的栗子中，创建实例时，是从底层往上层new的：
  
  在这个过程中，我需要了解整个car/framework/bottom/tire类的构造函数是怎么定义的，才能进一步new/注入。
  Ioc容器在进行这个工作的时候是反过来的，它先从最上层开始往下找依赖关系，到达最底层之后再往上一步一步new
  
  这里Ioc容器可以直接隐藏具体的创建对象的细节，像一个工厂：
  
  我们只需要关注是实例，而不需要关注如何创建实例。
  IoC 容器是 Spring 用来实现 IoC 的载体， IoC 容器实际上就是个Map（key，value）,Map 中存放的是各种对象。

2.5种依赖注入方法的优缺点：

• 构造函数注入：
  如果一个对象依赖的对象有n个，那么就需要增加这n个对象作为参数，导致构造函数过于庞大。栗子：
  public Car(ILogger log,IPerson iper,IFramework ifra,…){
  …
  }

• setter注入
  万一在没有在xml文件里指定要注入的对象，setter注入不会失败，只是所依赖的对象没有被注入任何对象，默认为null,即 会产生空指针异常。编译器不报错，运行期报错，这可不太好，有什么办法让其在编期就通不过吗，于是@required注解就诞生了，表示让setter注入的属性称为必填项

• 接口注入

• 注解注入

• Java Config

解耦精髓：==依赖的不是具体某一个，而是任意一个。==并不是完全的解耦，只是降低了耦合度。

二、Spring AOP：
AOP：面向切面编程。日志管理，事物处理，权限控制等都是利用AOP实现的。
Spring AOP 是基于动态代理的,如果要代理的对象，实现了(Implements)某个接口，那么Spring AOP 会使用JDK Proxy，去创建代理对象，而对于没有实现接口的对象就无法使用JDK Proxy去进行代理了，这时会用Cglib，生成一个被代理对象的==子类（Extends）==作为代理。
JDK动态代理采用的是实现，而Cglib采用的是继承。