Spring 5 中文解析核心篇-IoC容器之依赖关系
一个典型的企业应用不是由一个简单的对象(在中叫bean)组成。即使是最简单的应用程序，也有一些对象协同工作，以呈现最终用户视为一致的应用程序。(备注：相当于所有的bean一起协同工作对于用户是无感知的)。下一部分将说明如何从定义多个独立的Bean对象协作去实现应用程序的目标。
###### 1.4.1 依赖注入
依赖注入是从工厂方法构造或返回的实例并通过设置对象实例的构造参数、工厂方法参数或者属性去定义它的依赖关系(与它一起工作的对象)的过程。当创建的时候容器注入这些依赖。从根本上讲，此过程是通过使用类的直接构造或服务定位器模式来控制自身依赖关系的实例化或位置的本身的逆过程（因此称为控制反转）。
DI(依赖注入)使代码更简洁和解偶，当为这些对象提供依赖时候是更高效的。(通过依赖注入来注入对象更高效)。对象不用去主动查找它的依赖项并且不用知道依赖类的位置。这样的结果是我们的类变成了更容易被测试，特别地，当这些依赖在接口或者抽象类上时，在单元测试中去使用或者方式去实现这些接口和抽象类。
DI(依赖注入)存在两个重要的变体：和[基于Setter的依赖注入](https://docs.spring.io/spring/docs/5.2.6.RELEASE/spring-framework-reference/core.html#beans-setter-injection)
基于构造函数依赖注入
基于构造函数的DI(依赖注入)是通过容器调用构造函数完成的，每一个构造函数参数代表一个依赖。调用带有特定参数的静态工厂方法来构造Bean几乎是等效的，并且本次讨论将构函数和静态工厂方法的参数视为类似的。下面的例子展示了只能通过构造函数进行对象注入：
public class SimpleMovieLister {
// the SimpleMovieLister has a dependency on a MovieFinder
private MovieFinder movieFinder;
//构造函数注入MovieFinder对象
public SimpleMovieLister(MovieFinder movieFinder) {
this.movieFinder = movieFinder;
}
// business logic that actually uses the injected MovieFinder is omitted...
}注意：这个类没有任何特别的。它是一个POJO类并且没有依赖容器特定接口、基础类或注解。
构造函数参数解析
构造参数解析匹配是通过使用参数的类型进行的。如果bean定义的构造函数参数中不存在潜在的歧义，在bean定义中定义构造函数参数的顺序是在实例化bean时将这些参数提供给适当的构造函数的顺序。考虑下面的类
package x.y;
public class ThingOne {
public ThingOne(ThingTwo thingTwo, ThingThree thingThree) {
// ...
}
} 假设和类没有继承关系，不存在潜在的歧义。因此，这个配置工作的很好并且我们没有必要显示的在
当引用另一个bean时，类型是已知的，可以进行匹配。当一个简单类型被使用，例如
package examples;
public class ExampleBean {
// Number of years to calculate the Ultimate Answer
private int years;
// The Answer to Life, the Universe, and Everything
private String ultimateAnswer;
public ExampleBean(int years, String ultimateAnswer) {
this.years = years;
this.ultimateAnswer = ultimateAnswer;
}
}构造函数参数类型匹配
在前面的场景中，如果我们通过使用属性明确指定了构造函数参数类型，容器会使用简单类型进行匹配。像下面的例子：
构造函数参数索引
我们可以明确指定构造函数参数的索引通过属性，像下面例子：
除了解决多个简单值的歧义性之外，指定索引还可以解决歧义，其中构造函数具有两个相同类型的参数。
> index索引从0开始
构造函数参数名称
我们也可以使用构造函数参数名称来消除歧义，例如下面例子：
请记住，要使此工作开箱即用，必须在启用调试标志的情况下编译代码，以便Spring可以从构造函数中查找参数名称。如果不能或不想在debug标记下编译代码，可以使用JDK注解 去明确构造函数参数的名称。参考下面例子：
package examples;
public class ExampleBean {
// Fields omitted
@ConstructorProperties({"years", "ultimateAnswer"})
public ExampleBean(int years, String ultimateAnswer) {
this.years = years;
this.ultimateAnswer = ultimateAnswer;
}
}基于Setter依赖注入
基于的 DI(依赖注入)是在bean调用无参构造函数或无参工厂函数去实例化后被容器调用函数去完成的。
下面的例子展示了一个只能通过使用注入的类。这个类是常规的Java。它是一个POJO并且没有依赖容器特定接口、基础类或者注解。
public class SimpleMovieLister {
// the SimpleMovieLister has a dependency on the MovieFinder
private MovieFinder movieFinder;
// 通过Setter进行注入
public void setMovieFinder(MovieFinder movieFinder) {
this.movieFinder = movieFinder;
}
// business logic that actually uses the injected MovieFinder is omitted...
}支持基于构造函数和的依赖注入的管理。也支持在通过构造函数注入后再通过基于方法注入。可以使用的形式配置依赖项，将其与实例结合使用以从一种格式转换为另一种格式。然后，大多数用户不会直接使用这些类，而是使用XML的bean定义、注解这些组件(类似, 等等)，或者基于Java被标注类的方法使用标注。这些配置数据源内部地转换为实例并且被使用于加载整个容器实例。
> **基于构造函数和函数注入选择**
>
> 由于可以混合基于构造函数和函数的依赖注入，将构造函数用于强制性依赖项，将方法或配置方法用于可选性依赖项是一个很好的经验法则。需要注意在方法上使用 表明这个属性需要一个依赖；然而，构造函数注入可以通过编程方式校验参数是可取的。
>
> 团队一般推荐使用构建函数注入，因为可以允许我们去实现不可变的对象组件并且确保需要的依赖不为。此外，构造函数注入组件总是被返回一个完整初始化的状态。构造函数大量的参数是一个坏代码味道，暗示着这个有太多的责任并且应该去重构以更好的分离关注点问题。
>
> 注入应该主要使用在可选依赖因为可以在在类中设置一个默认值。否则，必须在代码使用依赖项的任何地方执行非空检查。注入的一种好处是可以在后面对方法进行重新配置或重新注入。
>
> 使用对特定类最有意义的DI样式，有时候，当处理第三方类库没有源码的时候，这个选择是非常适合的。例如：如果第三方类库没有暴露任何的方法，构造函数注入可能是依赖注入的唯一有效方式。
依赖解析处理
容器执行bean依赖解析过程：
* 通过对所有bean的配置元数据描述进行创建和初始化。配置元数据通过、或者注解描述。
* 对于每个，它的依赖形式通过属性、构造函数参数或者(如果使用常规的构造函数替换)方法参数表达。当这个bean被创建的时候，这些依赖被提供给。(备注：被依赖bean先创建)
* 每一个属性或者构造函数参数的都要设置一个实际的定义，或引用容器其他。
* 每一个属性或构造函数参数的值从指定的格式转换为属性或构造函数参数的真实类型。默认情况下，Spring提供一个字符串格式转换为所有内建类型的值，例如：int、long、String、boolan等等。
Spring容器验证每一个创建bean的配置。然而，bean属性本身没有被设置，直到bean被真正创建。在创建容器时，将创建单例作用域的bean并将其设置为预实例化(缺省值)。Scope被定义在 。除此之外，其他的bean创建仅仅在请求容器的时候。bean的创建潜在的导致一些bean的图被创建(备注：意思是bean所依赖的bean被创建，类似于bean的依赖拓扑图)，类似bean的依赖和它的依赖的依赖bean创建和被赋值。注意：这些依赖项之间的解析不匹配可能会在第一次创建受影响的bean时出现。
> 循环依赖
>
> 如果主要使用构造函数注入，则可能会创建无法解决的循环依赖场景。
>
> 例如：类通过构造函数需要依赖注入类并且类通过构造函数依赖注入。如果配置类和类相互依赖注入，**Spring IoC**容器在运行时检测到循环依赖会抛出一个异常。
>
> 一种解决方法是编辑类的源码通过而不是构造函数注入。或者避免使用构造函数注入而是仅仅使用方法注入。换句话说，虽然它是不推荐使用的，我们可以通过注入配置循环依赖对象。与典型情况（没有循环依赖关系）不同，Bean 和Bean 之间的循环依赖关系迫使其中一个Bean在完全初始化之前被注入另一个Bean（经典的“鸡与蛋”场景）
通常，你可以相信做的事情是正确的。容器会在加载时候检测配置问题，例如：引用不存在的、循环依赖。当这个被真正创建的时候，设置属性并且尽可能晚的解析依赖。这意味着如果创建该对象或其依赖项时遇到问题，则已正确加载的容器可能在你请求对象时生成异常-例如，这个抛出一个错误或无效的属性异常结果。这可能会延迟某些配置问题的可见性，这就是为什么默认情况下ApplicationContext实现会预先实例化单例bean的原因。在实际需要使用这些bean之前要花一些前期时间和内存，你会在创建ApplicationContext时发现配置问题，而不是以后(使用bean的时候)。你可以覆盖这个默认行为，这样单例bean就可以惰性地初始化，而不是预先实例化。
如果不存在循环依赖关系，则在将一个或多个协作bean注入到依赖中时，每个协作在注入到依赖中之前都已完全配置。也就是，如果**bean **有依赖**bean **，容器在调用**bean **的方法之前完整的配置**bean **。换句话说，这个bean被实例化，他的依赖被设置并且关联的生命周期函数(例如：或者[InitializingBean 回调函数](https://docs.spring.io/spring/docs/5.2.6.RELEASE/spring-framework-reference/core.html#beans-factory-lifecycle-initializingbean))已经被调用。
依赖注入例子
下面的例子基于XML配置元数据去配置基于的依赖注入。Spring XML配置文件指定一些bean的定义：
下面定义的类
public class ExampleBean {
private AnotherBean beanOne;
private YetAnotherBean beanTwo;
private int i;
// 指定属性需要注入bean类型
public void setBeanOne(AnotherBean beanOne) {
this.beanOne = beanOne;
}
// 指定属性需要注入bean类型
public void setBeanTwo(YetAnotherBean beanTwo) {
this.beanTwo = beanTwo;
}
public void setIntegerProperty(int i) {
this.i = i;
}
}上面的例子，在XML文件中通过声明属性匹配类型。下面例子使用构造函数注入：
下面例子对于的类定义
public class ExampleBean {
private AnotherBean beanOne;
private YetAnotherBean beanTwo;
private int i;
//需要在构造函数中声明需要依赖的类型定义
public ExampleBean(
AnotherBean anotherBean, YetAnotherBean yetAnotherBean, int i) {
this.beanOne = anotherBean;
this.beanTwo = yetAnotherBean;
this.i = i;
}
}定义中指定的构造函数参数用作构造函数的参数(意思是xml中指定的构造函数引用作为构造函数的参数)。
现在考虑这个例子的变体，使用构造函数替换，调用工厂方法去返回对象的实例：
对应的类定义：
public class ExampleBean {
// a private constructor
private ExampleBean(...) {
...
}
//静态工厂方法
public static ExampleBean createInstance (
AnotherBean anotherBean, YetAnotherBean yetAnotherBean, int i) {
ExampleBean eb = new ExampleBean (...);
// some other operations...
return eb;
}
} 静态工厂方法的参数由
> 参考代码：
###### 1.4.2 详细介绍依赖项和配置
在前面的章节提到，我们可以定义bean的属性和构造函数参数去引用其他被管理的bean(协同者)或者作为一个内联值定义。Spring的XML元数据配置支持子元素类型
直接值(原生类型、字符串等)
下面的例子使用命名空间使配置方式更简洁：
前面的XML配置非常的简洁，但是，拼写错误在运行时被发现而不是在设计时，除非我们使用IDE(例如：或者)支持自动属性完成当我们创建定义的时候。IDE助手是非常推荐的。
我们可以配置实例，例如：
jdbc.driver.className=com.mysql.jdbc.Driver
jdbc.url=jdbc:mysql://localhost:3306/mydb
Spring容器通过使用的PropertyEditor机制转换
元素
元素是一个简单的容错方式，将容器中另外bean的id传递(字符串值-不是引用)到
前面bean定义片段和下面的片段相同：
> 参考代码：
第一种形式优于第二种形式，因为使用标记可使容器在部署时验证所引用的名Bean实际上是否存在。在第二个变体中，不对传递给客户端bean的targetName属性的值执行验证。拼写错误仅在实际实例化客户端bean时才发现（最有可能导致致命的结果）。如果这个客户端bean是原型bean，这个拼写和结果异常可能在这个容器部署后很久才被发现。
> 在标签元素上的的属性在后不在支持。因为它没有提供常规的引用值。当升级到更改为
标签元素带来的价值的地方是在 定义中配置。指定拦截器名称时使用
引用其他的bean
元素是 或
指定目标bean通过标签的bean属性是最常见的形式并且允许在同一个容器或父容器引用任何的被创建的，而不管是否在同一个配置文件。bean属性的值可以与目标bean的id属性相同，也可以与目标bean的name属性中的值之一相同。下面例子展示怎样使用元素。
通过属性指定目标的引用，这个在当前容器的父容器中。属性的值可以与目标的属性或目标的属性中的值之一相同(或者指定引用)。这个目标必须在父容器中。当你有一个分层的容器并且你想去包装一个在父容器中存在的为代理对象同时有一个相同的名字作为这个父，你应该主要的使用这个应用的变体。下面的两个例子展示类怎样使用属性。
内部bean
一个内部定义不需要定义一个或名称。如果指定名称，这个容器不会使用这个值作为标识(不会使用定义的作为或标识)。容器在创建内部bean或忽略(作用域)，因为内部总是匿名的并且总是依赖外部的创建。不可能独立访问内部或将它们注入到协作中而是封装在中。一个极端的情况，可能接受定制的Scope的销毁回调-例如：一个请求域内部包含在一个单例中。内部bean实例的创建与其包含的bean绑定在一起，但是销毁回调使它可以参与请求范围的生命周期。这不是常见的情况。内部bean通常只共享其包含bean的作用域。
> 参考代码：
集合
、
administrator@example.org
support@example.org
development@example.org
just some string
Map key的值、值、或者set的值，可以是任何下面元素：
bean | ref | idref | list | set | map | props | value | null> 参考代码：
集合合并
Spring容器也支持对集合合并。应用程序开发人员可以定义、、
、、
在合并章节讨论父-子bean的机制。不熟悉父bean和子bean定义的读者可能希望先阅读部分，然后再继续。
下面的例子展示集合的合并：
administrator@example.com
support@example.com
sales@example.com
support@example.co.uk
注意：在的定义的属性的
administrator=administrator@example.com
sales=sales@example.com
support=support@example.co.uk 为了支持在父值被覆盖，子集合的值从父
这个合并行为适用类似、、
元素的特定情况下，将维护与List集合类型关联的语义（即，值有序集合的概念）。父元素的值优先与所有的子元素值。在、和集合类型中不存在顺序。因此，对于容器内部使用的关联、和实现类型下的集合类型，没有有效的排序语义。
集合合并限制
我们不能合并不同集合类型(例如：Map和List)。如果尝试去合并将会抛出一个Exception异常。这个merge属性必须被指定在子类中。在父集合定义中指定merge属性是多余的并且不会达到预期结果。
强类型集合
在Java 5中泛型被引入，我们可以使用强类型集合。因此，仅仅包含元素的集合声明成为可能。如果我们使用Spring去依赖注入一个强类型的Collection到一个bean中，可以利用Spring的类型转换在添加到Collection集合前对集合实例元素转换为适合的类型。下面的java代码和bean定义展示了怎样去使用：
public class SomeClass {
private Map accounts;
public void setAccounts(Map accounts) {
this.accounts = accounts;
}
}
当准备注入 **bean**的属性时，可以通过反射获得有关强类型的元素类型的泛型信息。因此，的类型转换基础设施识别各种元素类型的值并且这些字符串值能够被转换为真实的类型。
Null和空字符串值
Spring将属性等的空参数视为空字符串。下面基于XML的配置元数据片段设置了email属性为空字符串
和下面java代码相等：
exampleBean.setEmail("");
和下面java代码相等：
exampleBean.setEmail(null);快捷方式
让你使用元素的属性(嵌入元素
Spring支持可扩展的配置格式，基于XML Schema定义。本章讨论的bean配置格式在XML Schema文档中定义。然而，在XSD文件中没有被定义仅仅在中存在。
下面例子展示两个XML片段其解析结果是一致的.
该示例显示了中的一个属性，该属性在bean定义中称为。这告诉包含一个属性的声明。前面提到，没有定义，因此你可以设置属性名称为(类字段)名称。
下一个示例包括另外两个bean定义，它们都有对另一个bean的引用：
这个例子包含了不仅属性值使用而且还使用指定格式去声明属性引用。第一个定义使用
> 不像标准的XML格式灵活。例如，声明属性引用的格式与以Ref结尾的属性冲突，而标准XML格式则不会。我们推荐你选择你的方式小心地并和你的团队交流去避免在用一时间同时使用XML三种方式。
> 参考代码：
快捷方式
类似快捷方式，在引入，允许配置构造函数参数内联属性而不是嵌入元素。
命名空使用类似于相同的约束(引用为跟随)去通过它们的名字设置构造参数。类似地，即使它没有在中定义，也需要在XML文件中去声明，(存在中)。
一个少见的场景，构造函数参数名字不能使用(通常如果编译字节码时没有调试信息)可以使用回退参数索引，如下：
> 由于XML语法，要求这个索引符号必须存在，因为XML属性名称不能以数字开头(即使IDE工具允许也是不行的)。对应索引的符号在
在实践中，构造函数解析机制在匹配参数是非常高效的，因此，除非你真的需要，我们推荐整个配置都使用名字符号。
> 参考代码：
复合属性名
当设置属性的时候，我们可以使用复合或嵌入属性名，只要这个(点式引用)下面所有组件期望这个最终属性名不为。考虑下面的定义：
这个 bean有一个属性，有一个属性，拥有一个属性并且最终属性被设置值为。为了能正常工作，的属性和的属性在这个构造之前必须不能为。否则，会抛出一个。
###### 1.4.3 使用
如果依赖其他，也就是意味着bean需要设置依赖的属性。典型地，我们可以基于XML配置元数据使用去完成。然而，一些bean之间的依赖不是直接的。一个例子是在类中一个静态的初始化器需要被触发，例如：数据库驱动注册。属性能够显示地强制一个或多个在依赖初始化之前初始化。下面的例子使用属性去表达对一个简单的依赖。
为了表达多个bean的依赖，提供一个bean名称的集合列表作为属性值(、、是有效的分隔符)。
> 仅仅在场景下，属性能够指定初始化时间依赖和对应的销毁时间依赖。与给定bean定义依赖关系的从属bean首先被销毁，然后再销毁给定bean本身(备注：被依赖的bean先销毁，在销毁宿主bean)。因此，可以控制关闭顺序。
参考代码：
###### 1.4.4 bean的懒加载
默认情况下，实现更早的创建和配置所有的作为初始化过程的一部分。通常地，这个前置初始化是可取的，因为错误的配置或环境变量被立即的发现，而不是几个小时甚至几天后才被发现。当这个行为不是可取的时候，我们可以通过标记作为一个懒加载的单例去阻止提前初始化。一个懒加载告诉容器当第一次请求的时候去创建实例而不是在容器启动时候。
在XML配置中，这个行为通过在
当前面的配置通过加载并启动时，这个 bean没有被提前的初始化，而 bean被尽早的初始化。
然而，当一个懒加载bean是另一个单例的依赖时候，这个懒加载不是懒加载的。在启动时创建这个懒加载，因为它必须满足这个单例的依赖。这个懒加载被注入到一个单例所以它不是懒加载的。
我们也可以在容器级别通过使用
参考代码：
###### 1.4.5自动装配协调者
Spring容器能自动装配协调者bean之间的关系。通过检查的内容，Spring自动为你的bean解析协同者(其他依赖bean)。自动装配有下面的优势：
自动装配能显著的降低对属性和构造函数参数的需要。(其他机制例如：在这方面，其他机制（例如本章其他地方讨论的bean模板）也很有价值)。
自动装配可以随着对象的演化而更新配置。例如：如果你需要添加一个类的依赖，依赖能够被自动地被满足不需要修改配置。因此，自动装配在开发过程中特别有用，当代码库变得更加稳定时，自动装配可以避免切换到显式连接的选项。
当使用基于XML元数据配置，我们可以为这个指定自动装配模式通过
使用或构造函数自动装配模式，你可以结合数组和类型化的集合，在这种情况下，提供容器中与期望类型匹配的所有自动装配候选，以满足相关性。如果期望的 类型是，你可以自动装配强类型的实例。一个自动装配实例的值由所有匹配期望类型实例组成，并且这个Map实例的这些与名称对应。
自动装配的优势和限制
在一个系统中一致地使用自动装配将工作的更好。如果通常不使用自动装配，则可能使开发人员仅使用自动装配来连接一个或两个bean定义而感到困惑。
考虑自动装配的限制和优势：
* 在和中显示依赖设置总是覆盖自动装配。你不能自动装配简单的属性例如：原生类型，和(简单属性数组)。这种限制是由设计造成的。
* 自动装配没有显示装配精确。尽管如前面的表中所述，小心地避免猜测，以免产生可能产生意外结果的歧义。管理对象之间的关系不再明确记录。
* 装配信息可能对从容器生成文档的工具不可用。
* 容器中的多个定义可能与要自动装配的方法或构造函数参数指定的类型相匹配。对于数组、集合或实例，这不一定是问题。然而，为了依赖期望一个简单值，这种歧义不会被任意解决(意思是期望一个容器中确有多个匹配的)。如果没有唯一的有效的定义会抛出一个异常。
在最后的场景中，你有一些可选项：
* 显示的装配放弃自动装配。
* 通过设置
自动装配排除bean
在每个bean的基础上，你可以从自动装配中排除一个。在的XML格式中，设置
> autowire-candidate属性被设计仅仅通过基于类型自动装配有影响。它不会影响通过名字来显示引用的方式，即使这个指定bean没有被标记作为一个自动装配候选者这个名字也会被解析。因此，如果名称匹配，按名称自动装配仍然会注入Bean。
可以基于与名称的模式匹配来限制自动装配候选者。顶层
当这些不想自动装配注入到其他中时，这些技术是非常有用的。这并不意味着一个被排除的本身不能通过使用自动装配来配置。而是，本身不是一个候选者不会被注入到其他中。
> 参考代码：
###### 1.4.6 方法注入
在大多数应用场景中，在容器中大多数是单例的。当单例需要与另一个单例协作或非单例需要与另一个非单例协作时，典型的处理依赖通过定义一个作为其他的属性。当的生命周期不同时会出现问题。假设单例bean 需要使用非单例bean (原型)，假设的每个方法被调用。这个容器仅仅创建单例bean 一次并且只有一次机会去设置属性。容器无法每次为bean 提供一个新的bean 实例(单例A每次从容器获取bean 不能每次提供一个新)。
一个解决方案时放弃控制反转。我们也可以通过实现接口让bean 意识到容器。并在bean 每次需要bean 时，通过使用获取一个新实例。下面例子展示使用方式：
package fiona.apple;
// Spring-API imports
import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;
public class CommandManager implements ApplicationContextAware {
private ApplicationContext applicationContext;
public Object process(Map commandState) {
// grab a new instance of the appropriate Command
Command command = createCommand();
// set the state on the (hopefully brand new) Command instance
command.setState(commandState);
return command.execute();
}
protected Command createCommand() {
// 通过从容器获取bean
return this.applicationContext.getBean("command", Command.class);
}
public void setApplicationContext(
ApplicationContext applicationContext) throws BeansException {
//容器注入ApplicationContext
this.applicationContext = applicationContext;
}
}上面的例子不是可取的，因为这个业务代码需要容器回调耦合了 框架(备注：这个我不敢苟同，上面我也发表了观点)。方法注入，容器高级特性，让我们处理这种场景更简洁。(备注：上面配置为原型才能达到效果)
查找方法注入
查找方法注入是容器覆盖容器管理上的方法并返回容器中另一个命名的查找结果的能力。在前面描述的场景中，典型地查找涉及到原型bean。框架通过库去动态地生成一个子类去覆盖这些方法以实现方法注入。
> * 为了动态子类能够正常工作，不能是并且方法也不能是。
> * 单元测试一个具有抽象方法的类需要你自己去子类化并且提供一个抽象方法的存根实现。
> * 组件扫描也需要具体方法，这需要具体的类别。
> * 进一步关键限制是方法查找不能在工厂方法并且特别在类被标注的方法，因为，在这种情况，容器不负责创建实例，因此无法即时创建运行时生成的子类(因为这种方法是由我们自己创建处理的容器不能控制的生成)。
在前面的代码片段中，容器动态的覆盖这个方法的实现。类没有任何的的依赖，重构如下：
package fiona.apple;
// 没有Spring的依赖!
public abstract class CommandManager {
public Object process(Object commandState) {
// grab a new instance of the appropriate Command interface
Command command = createCommand();
// set the state on the (hopefully brand new) Command instance
command.setState(commandState);
return command.execute();
}
// okay... but where is the implementation of this method?
protected abstract Command createCommand();
}在客户端类中包含被注入的方法(在这个例子中是类)，这个方法被注入要求一个下面格式的签名：
[abstract] theMethodName(no-arguments); 如果这个方法是，动态地生成子类实现这个方法。除此之外，动态生成子类覆盖在源类中具体方法定义。考虑下面例子：
每当需要新的 实例时，标识为的bean就会调用其自己的方法。你必须非常的小心应用作为一个原型，如果这是真实需要的。如果这个是单例的，实例每次都返回同一个。
或者，在基于注解组件模式中，你可以声明一个查找方法通过注解，像下面例子：
public abstract class CommandManager {
public Object process(Object commandState) {
Command command = createCommand();
command.setState(commandState);
return command.execute();
}
//指定名称查找，在容器中查找
@Lookup("myCommand")
protected abstract Command createCommand();
}或者，更习惯地说，你可以依靠针对查找方法的声明返回类型来解析目标：
public abstract class CommandManager {
public Object process(Object commandState) {
MyCommand command = createCommand();
command.setState(commandState);
return command.execute();
}
//没有指定名称查找，通过查找方法的MyCommand类型去容器查找
@Lookup
protected abstract MyCommand createCommand();
}注意，通常应该使用具体的存根实现声明此类带注解的查找方法，为了使它们与的组件扫描规则兼容，默认情况下，抽象类将被忽略。此限制不适用于显式注册或显式导入的类。
> 获取不同范围的目标bean的其他方式是/注入点。查看 .
>
> 你也可以找到(在包)去使用。
> 参考代码：
>
>
>
>
任意方法替换
与查找方法注入相比，方法注入的一种不太有用的形式是能够用另一种方式实现替换托管中的任意方法。你可以放心地跳过本节的其余部分，直到你真正需要此功能为止。
基于XML元素数据配置，你可以使用元素将现有的方法实现替换为已部署的。考虑下面的类，这个类有一个叫做的方法我们想去覆盖这个方法。
public class MyValueCalculator {
public String computeValue(String input) {
// some real code...
}
// some other methods...
}类实现接口提供新的方法定义，像下面定义：
public class ReplacementComputeValue implements MethodReplacer {
public Object reimplement(Object o, Method m, Object[] args) throws Throwable {
// get the input value, work with it, and return a computed result
String input = (String) args[0];
...
return ...;
}
}的定义去部署到源类并且指定方法覆盖类似如下例子：
String
你可以使用一个或多个
为了方便起见，参数的类型字符串可以是完全限定类型名称的子字符串。例如：：
java.lang.String
String
Str因为参数的数量通常足以区分每个可能的选择，所以通过让你仅输入与参类型匹配的最短字符串，此快捷方式可以节省很多输入。
> 参考代码：
作者
个人从事金融行业，就职过易极付、思建科技、某网约车平台等重庆一流技术团队，目前就职于某银行负责统一支付系统建设。自身对金融行业有强烈的爱好。同时也实践大数据、数据存储、自动化集成和部署、分布式微服务、响应式编程、人工智能等领域。同时也热衷于技术分享创立公众号和博客站点对知识体系进行分享。
博客地址： http://youngitman.tech
CSDN： https://blog.csdn.net/liyong1028826685
微信公众号：
