[TOC] 本文改编自[Spring的本质系列](https://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg==&mid=2665513179&idx=1&sn=772226a5be436a0d08197c335ddb52b8&scene=21#wechat_redirect) ## 对象的创建 面向对象的编程语言是用类 (Class) 来对现实世界进行抽象， 在运行时这些类会生成对象(Object)。当然单独的对象没有办法完成复杂的业务，实际系统是由千千万万个对象组成的，而且他们需要相互协作。那么对象A入耳才能获得对象B的引用呢？ 最简单的方法无非是，当对象A需要使用B的时候，才把它**new**出来。例如 ``` Apple a = new Apple(); ``` 后来业务更复杂了，就抽象出一个Fruit类，创建的对象都赋给fruit的一个实例。 ~~~ Fruit f1 = new Apple(); Fruit f2 = new Banana(); Fruit f3 = ...... ~~~ 这样的代码如果散落在各处，维护起来将会痛苦不堪。 那么也可以能出现如下的工厂类  工厂模式，以及抽象工厂， Builder 模式提供的都是创建对象的方法。背后体现的都是**封装变化**的思想 这些模式只是一些最佳实践而已： 起了一个名称、描述一下解决的问题、使用的范围和场景，码农们在项目中还得自己去编码实现他们。 ## 解除依赖 一个订单处理类，它会被定时调用： 查询数据库中订单的处理情况， 必要时给下订单的用户发信。  这里就需要很多类一起协作了，尤其是OrderProcessor，它依赖于OrderService和EmailService两个服务，它获取依赖的方式就是通过**单例方法** 但是如果你想对这个 process 方法进行单元测试，就会发现 * OrderService会从数据库中取到Order的信息，需要确保数据库中有数据，而且数据库连接有问题。如果是数据连接Container(例如Tomcat)管理数据连接的，那么没有Tomcat很难建立数据库连接 * 这个 EmailService 真的会对外发邮件， 你可不想对真正的用户发测试邮件，当然你可以修改数据库，把邮件地址改成假的，但那样很麻烦， 并且 EmailService 会抛出一堆错误来，很不爽 所有的这些障碍， 最终会导致脆弱的单元测试： **速度慢， 不可重复，需要手工干预，不能独立运行。** 一个可行的办法就是不在方法中直接调用OrderService和EmailService的getInstance()方法，而是通过setter方法传进来。  也就是构建一个假的 OrderService 和假的 EmailService 了。 例如 OrderService 的冒牌货可以是 MockOrderService , 它可以返回你想要的任何 Order 对象， 而不是从数据库取。MockEmailService 也不会真的发邮件， 而是把代码中试图发的邮件保存下来， 测试程序可以检查是否正确。  那么你会发现需要把OrderService和EmailService变成接口或者抽象类，这样才能把Mock对象传进来。 这其实也遵循了面向对象编程的另外一个要求：**对接口编程， 而不是对实现编程** ## Spring依赖注入 上面的代码其实就是实现了一个依赖的注入，把两个冒牌货注入到业务类中 (通过 set 方法)， 这个注入的过程是在一个测试类中通过代码完成的。 既然能把冒牌货注入进去， 那毫无疑问，肯定也能把一个正经的类安插进去， 因为 setter 方法接受的是接口，而不是具体类。  用这种方式来处理对象之间的依赖， 会强迫你对接口编程， 好处显而易见。 随着系统复杂度的增长， 这样的代码会越来越多， 最后也会变得难于维护。 能不能把各个类之间的依赖关系统一维护呢？ 能不能把系统做的更加灵活一点，用声明的方式而不是用代码的方式来描述依赖关系呢？ 在 Java 世界里，如果想描述各种逻辑关系， XML 是不二之选：  只有xml还不够，还缺少一个解析器，假设为XmlAppContext * 解析xml，获得各种元素 * 通过**Java反射**把各个bean的实例创建起来。com.coderising.OrderProcessor , OrderServiceImpl, EmailServiceImpl. * 通过**Java反射**调用OrderProcessor 的两个方法：setOrderService(....) 和 setEmailService(...) 把 orderService , emailService 实例 注入进去。 应用程序使用起来就简单了： ~~~ XmlAppContext ctx = new XmlAppContext("c:\\bean.xml"); OrderProcessor op = (OrderProcessor) ctx.getBean("order-processor"); op.process(); ~~~ pring 的处理方式和上面说的非常类似， 当然 Spring 处理了更多的细节，例如不仅仅是 setter 方法注入， 还可以构造函数注入，init 方法， destroy 方法等等， 基本思想是一致的。  既然对象的创建过程和装配过程都是 Spring 做的， 那 Spring 在这个过程中就可以玩很多把戏了， 比如对你的业务类做点字节码级别的增强， 搞点 AOP 什么的， 这都不在话下了。 ## IoC vs DI 在好莱坞，把简历递交给演艺公司后就只有回家等待。由演艺公司对整个娱乐项目完全控制，演员只能被动式的接受公司的差使, 在需要的环节中，完成自己的演出。 这和软件开发有一定的相似性， 演员们就像一个个 Java Object, 最早的时候自己去创建自己所依赖的对象， 有了演艺公司（Spring 容器）的介入，所有的依赖关系都是演艺公司搞定的， 于是控制就翻转了 Inversion of Control, 简称 IoC。 但是 IoC 这个词不能让人更加直观和清晰的理解背后所代表的含义， 于是 Martin Flower 先生就创造了一个新词 : 依赖注入 (Dependency Injection，简称 DI), 是不是更加贴切一点？ ## AOP AOP（Aspect Oriented Programming）也就是面向切面编程 ### 问题来源 做系统设计的时候，非常重要的工作是把一个大系统分解，按照业务功能分解成一个一个低耦合、高内聚的模块 分解后会发现有很多有趣的东西，比如下面的模块是通用的。 * 日志 * 安全 * 性能 * 事务  这些非功能需求，但他们是多个业务模块都需要的，最简单的方法是把这些通用的模块写好，然后写业务模块的时候去调用就可以了。但是这样的话，日志、性能等无关的代码可以把真正的业务代码淹没了。  ## 模板方法 用设计模式可以部分解决如上的问题。比如模板方法 在父类(BaseCommand）中把乱七八糟的非功能代码都写好，只留了一个口最长（抽象方法doBusiness)让子类实现  子类就只需要关注业务逻辑了。 ``` BaseCommand cmd = ... 获得 PlaceOrderCommand 的实例... cmd.execute(); ``` 但是这种方案的巨大缺陷在于父类会定义一切，要执行那些非功能代码，以什么顺序执行等等。 子类只能无条件接受，完全没有反抗余地 ## 装饰者模式  让PlaceOrderCommand能打印日志，进行性能统计 ``` Command cmd = new LoggerDecorator( new PerformanceDecorator( new PlaceOrderCommand())); cmd.execute(); ``` 如果 PaymentCommand 只需要打印日志，装饰一次就可以了 ``` Command cmd = new LoggerDecorator( new PaymentCommand()); cmd.execute(); ``` 可以使用任意数量的装饰器，而且还可以以任意次序执行，非常的灵活 ## AOP 但是装饰者有很多问题： * 一个处理日志、性能、事务的类为什么要实现业务接口(Command)呢？ * 如果别的业务模块，没有实现Command接口，但是也想利用日志、性能、事务等，应该怎么办呢？ 最好把日志、安全、事务这些代码与业务代码隔离出来，因为他们的关注点与业务代码的关注点完全不同。  如果把这个业务功能看成一层层面包的话， 这些日志 / 安全 / 事务 像不像一个个 “切面”(Aspect) ？ 如果我们能让这些 “切面“能和业务独立， 并且能够非常灵活的“织入” 到业务方法中， 那就实现了面向切面编程(AOP)！ ## 实现AOP 现在我们来实现 AOP 吧， 首先我们得有一个所谓的 “切面“类(Aspect)， 这应该是一个普通的 java 类 ， 不用实现什么“乱七八糟” 的接口。  我们对于 com.coderising 这个包中所有类的 execute 方法， 在方法调用之前，需要执行 Transaction.beginTx() 方法， 在调用之后， 需要执行 Transaction.commitTx() 方法。 “对于 com.coderising 这个包中所有类的 execute 方法” ， 用一个时髦的词来描述就是切入点（PointCut） , 它可以是一个方法或一组方法（可以通过通配符来支持，你懂的） ” 在方法调用之前 / 之后 ， 需要执行 xxx“ , 用另外一个时髦的词来描述就是通知（Advice）  注意：现在 Transaction 这个类和业务类在源代码层次上没有一点关系，完全隔离了。 但是Java是一门静态的强类型语言， 代码一旦写好， 编译成 java class 以后 ，可以在运行时通过反射（Reflection）来查看类的信息， 但是想对类进行修改非常困难。 而 AOP 要求的恰恰就是在不改变业务类的源代码（其实大部分情况下你也拿不到）的情况下， 修改业务类的方法, 进行功能的增强，**就像上面给所有的业务类增加事务支持。** 目前有如下几种技术： * 编译的时候把日志、安全、事务等切面代码与业务逻辑编译到一起去。 * 运行的时候，业务类加载以后， 通过 Java 动态代理技术为业务类生产一个代理类， 把 “切面” 代码放到代理类中， Java 动态代理要求业务类需要实现接口才行。 * 在运行期， 业务类加载以后， 动态的使用**字节码**构建一个业务类的子类，将 “切面” 逻辑加入到子类当中去, CGLIB 就是这么做的。 Spring 采用的就是 (1) +(2) 的方式