Spring核心——Bean的依赖注入

「爱情、让人受尽委屈。」 2021-12-17 00:11 305阅读 0赞

### 依赖注入 ###

在[设计模式与IoC][IoC]这篇文章中，介绍了Spring基础的三大支柱的两项内容——IoC、Bean。本篇将继续围绕着Bean的创建时的注入方式来介绍Spring的核心思想与设计模式。

天底下所有面向对象的语言都不可能只用一个类来解决问题，即使是最简单的应用程序都存在类与类之间的依存关系。如下面这个人人都理解的组合例子：

class Foo{
       private Other other;
       public Foo(){
          other = new Other();
       }
    }
    
    class Other{}

在设计模式上关于类的组合与继承的适用性不属于本篇的讨论范围，但是从Spring框架非侵入式的设计思路来看，组合才是使用Spring的正确姿势。

官方将这种组合的关系叫做“依赖注入（DI——*Dependency injection*）”。从名字上来看这也是一种依托Ioc容器很自然的实现方式——所有的Bean都放置在容器中，然后通过一些配置来告诉容器bean与bean之间的依存关系。一个类除了在内部块中通过new关键字实现一个组合关系，也可以通过构造方法传参或接口方法设置。

由于IoC容器不可能去修改一个类内部的代码，所以类与类的组合方式通过构造方法（Constructor）和set方法（Setter）来实现。此外，Ioc可以根据接口（interface）来注入对应的实现类（class extands interface）,所以从设计模式的角度来说，依赖注入的方式很好的规避了**标准组合模式**中new关键字违反**依赖倒置原则**的问题。

### 构造方法注入 ###

直接通过构造方法注入组合数据。

class：

package x.y;
    
    public class A {
        private B b;
        private C c;
        public Foo(B b, C c) {
           this.b = b;
           this.c = c;
        }
    }
    public class B {}
    public class C {}

xml：

如果是源生类型的参数，可以通过指定类型来注入数据：

package x.y;
    
    public class A {
        private int b;
        private String c;
        public Foo(int b, String c) {
           this.b = b;
           this.c = c;
        }
    }

也可以通过索引的方式：

配合[@ConstructorProperties][ConstructorProperties]注解，还可以直接使用名称来注入：

package x.y;
    
    public class A {
        private int b;
        private String c;
        @ConstructorProperties({"b", "c"})
        public Foo(int b, String c) {
           this.b = b;
           this.c = c;
        }
    }

在Debug模式下不用这个注解也可以实现按名字注入，但是千万别这样做。

### Set方法注入 ###

package x.y;
    
    public class A {
        private B b;
        private C c;
        private String value;
        public void setA(A a){this.a = a;}
        public void setB(B b){this.b = b;}
        public void setB(String value){this.value = value;}
    }
    public class B {}
    public class C {}

### 使用 Constructor还是Setter？ ###

2种注入方法在使用的过程中我们应该如何选取呢？Spring官方给出的答案是如果注入的数据或bean是一个“必要依赖”那么使用构造方法注入，如果属于配置性的非必须数据，使用Set方法注入。但是在实际应用时，会发现绝大部分注入方式都是通过Setter实现的，包括一些很流行的开源工具，例如下面的druid：

话说你不提供账户和密码能链接到数据库吗？这算必要依赖还是配置性依赖？所以也不用死守这些规则。下面是一些关键性的建议：

1.  数据配置类使用constructor注入的方法来实现，因为这样可以将bean设置为一个不可变对象（*immutable objects*）。这样结合单例模式能够很好实现享元模式共享数据，结合原型模式可以创建“浅对比”对象（变更则替换）。
2.  如果构造函数要传入的参数太多，证明你的类要完成的责任太多，这个时候用Setter当然比较合理，但是建议回头去看看类当中是不是有可以拆分的功能。给你们推荐一个学习java的平台659270626，趁年轻，使劲拼，给未来的自己一个交代！
3.  Setter注入主要用于可选的依赖关系，如果没有设置值，类应该提供默认值。所以Setter方法应该检查传入值的有效性（not null、not blank等）。
4.  如果出现了循环依赖，其实可以通过一个bean使用setter注入另外一个bean使用constructor注入来解决，不过最好检查一下代码为什么会循环，这是设计模式上的大忌。
5.  最有一个建议最重要。如果用第三方类，别人给什么你只能用什么，没得选。

### 注入参数 ###

在XML配置中，用来设定注入方式和注入数据的XML标签很多，详细内容就不一一复述了，常规用法可以到官网 [Dependencies and configuration in detail][]  一节了解。这里仅仅说明一些要点：

1.  父子Bean。Ioc容器提供Bean的父子关系配置。父子关系Bean可以进行数据合并，但是很少看见什么地方有实际应用。
2.  <idref>标签和<ref>标签的差异：1)前者只能通过id引入，后者可以通过id或name引入；2)前者可以直接用value属性替换，但是value属性的效率会差很多；3)前者只能适用与当前配置文件或当前容器，后者可以引入任何位置的内容。
3.  当需要设置一个null值时，用<null>标签代替value=""。在执行代码时直接传入一个null。

### 自动装配 ###

这里所说的自动装配是通过<bean>上的autowire属性实现的功能，与@Autowired注解并不是一回事，但是他的一些参数会影像@Autowired注解的行为。

在有@Autowired注解的情况下，autowire属性现在用得很少。基本上他实现的结果和@Autowired差不多，就是让Ioc容器根据bean的类型或者bean名称等自动将容器中其他能对应得上的bean注入到对于的构造方法或者set方法中。详情了解 [Autowiring collaborators][]。

### 方法注入 ###

如果每一个Bean都是单例模式，那么我们通过常规的XML配置引用的手段就可以实现所有的依赖组合关系。但是每个bean都有不同的生命周期，常规配置方法很难实现某些应用不同生命周期bean的依赖关系。

第一种方式是通过继承 ApplicationContextAware 类，继承后可以直接使用 applicationContext 的 getBean 接口来获取任何一个 bean。

package x.y;
    import org.springframework.beans.BeansException;
    import org.springframework.context.ApplicationContext;
    import org.springframework.context.ApplicationContextAware;
    
    public class BeanManagerFoo implements ApplicationContextAware {
    
        private ApplicationContext applicationContext;
    
        public <T> T getBean(Class<T> type){
    		return applicationContext.getBean(type);
    	}
    
        public Object getBean(String id){
    		return springContext.getBean(id);
    	}
    
        public void setApplicationContext(
                ApplicationContext applicationContext) throws BeansException {
            this.applicationContext = applicationContext;
        }
    }

第二种方法是使用Lookup Method。

Lookup Method的实现思路是使用CGLIB生成了动态代理类并放置到Ioc中代替源生的类。看下面的例子。

首先实现我们的抽象类，抽象的要求至少有一个抽象方法：

package x.y;
    
    public abstract class A {
        public String getName() {
            B b = this.createB();
            return b.getName();
        }
    
        protected abstract B createB();
    }
    
    public class B {
        private String name = "B class";
        public String getName(){
            return this.name;
        }
    }

然后通过<lookup-method>标签来指定获取bean的方式：

现在，在调用A.getName方法时都会创建一个新的B类实例。需要注意scope属性，如果修改为[singleton][]则每次都获取同一个B实例。

使用动态代理由于是字节码级别的变换，所有有很多限制需要注意：方法和类都不能用fina关键字；测试用例需要自己实现代理模式，否则抽象类没有实现；

第三种方法是使用委派模式，即我们执行A.compute方法时，实际执行的是被委派的B.reimplement方法。

先定义2个基础类——Origin、Replace：

package x.y
    public class Origin {
        public int compute(int in1, int in2) {
            return in1+in2;
        }
    }
    
    public class Replace {
        public int reimplement(Object o, Method m, Object[] args) {
            int in1 = (int)args[0];
            int in2 = (int)args[1];
            return in1+in2;
        }
    }

然后定义Spring配置：

这个时候，在任何时候执行“origin”这个bean的compute方法，实际上都是执行的Replace::reimplement方法。

上面<arg-type/>的参数用全称或简写都可以，例如java.lang.String，使用String，Str都是指向这个类型。

使用委派模式的好处是限制少、灵活，并且不会用到CGLIB这种重量级工具。但是委派之后委派方法的真实参数和被委派方法的参数完全不一样，开发时需要时时刻刻紧跟委派类的结构来修改代码。一旦委派类发生任何修改而没有相应的调整被委派类，可能会出现意想不到的问题。

[IoC]: https://www.chkui.com/article/spring/spring_core_design_pattern_and_ioc
[ConstructorProperties]: http://download.oracle.com/javase/6/docs/api/java/beans/ConstructorProperties.html
[Dependencies and configuration in detail]: https://docs.spring.io/spring-framework/docs/current/spring-framework-reference/core.html#beans-factory-properties-detailed
[Autowiring collaborators]: https://docs.spring.io/spring-framework/docs/current/spring-framework-reference/core.html#beans-factory-autowire
[singleton]: https://docs.spring.io/spring-framework/docs/current/spring-framework-reference/core.html#beans-factory-scopes-singleton