Spring的IOC

1.系统设计:
    我们在做系统设计的时候,一个非常重要的工作就是把一个大系统做分解,按业务功能分解成一个个低耦合,高内聚的模块.
    
    分解之后,会发现有一些东西是通用的:
    日志: 对特定的操作输出日志来记录
    安全: 在执行操作之前进行操作检查
    性能: 要统计每个方法的执行时间
    事务: 方法开始之前要开始事务,结束后要提交或回滚事务
    
2.抽取公共部分:
    最简单的办法就是把这些通用模块的接口写好， 让程序员在实现业务模块的时候去调用
    
3.问题:
    调用时,会有很多的公共代码,而这些代码要把我们真正的业务逻辑代码掩盖了,降低代码的维护性
    
4.设计模式: 模板方法
    父类（BaseCommand）中已经把那些“乱七八糟“的非功能代码都写好了， 只是留了一个口子（抽象方法doBusiness()）让子类去实现。
    设计缺陷: 父类会定义一切,要执行哪些功能代码,以什么顺序执行都是固定了的,子类只能无条件接受
    
5.设计模式: 装饰者模式
    我们的业务类和装饰类(日志/事务)实现同一个业务接口,装饰对象来加强我们的业务对象
    不爽之处: 
        1.处理日志/事务的类为什么要实现业务接口呢?
        2.如果别的业务模块,没有实现这个业务接口,也想使用日志/事务的功能怎么办?    
    
6.Spring的AOP
    大体概念:
        我们在Spring中配置需要切面的业务方法,然后自定义一个切面类(普通的java类),写一个环绕通知方法(里面放日志/事务这种公共的操作),
        在执行业务方法的之前/之后都可以植入公共的代码.
        
    切入点: 根据配置,需要切入的业务方法
    通知: 在方法调用之前/之后,执行xxx
    
    使用AOP的好处: 
        切面类和业务类在源代码的层次上,没有一点关系,完全隔离了

    隔离问题:
        Java是一门静态的强类型语言,代码一旦写好,编译成java class以后,可以在运行时通过反射来查看类的信息,但是想对类修改非常的困难.
        而AOP要求的恰恰就是在不改变业务类的源代码的情况下,修改业务类的方法,进行功能的增强,就像上面说的给所有的类增加事务支持.
        
    解决方法:
        XML配置文件: 1.在编译的时候,根据AOP的配置信息,悄悄把日志,事务等"切面"代码和业务类编译到一起去.
        JDK动态代理: 2.在运行期,业务类加载以后,通过Java动态代理技术为业务类生产一个代理类,把"切面"代码放到代理类中,Java动态代理要求业务类需要实现接口才行.
        CGlib代理:   3.在运行期,业务类加载以后,动态的使用字节码构建一个业务类的子类,将"切面"逻辑放到子类当中去,CGlib就是这么做的