7.8.2: Use sub-bean

With the applicationProgramAs the scale increases, the growth of spring configuration files is faster. When there are more and more components in the application, the bean configuration in the spring configuration file also increases greatly, and a phenomenon will gradually emerge: a large number of bean configurations are identical, only a small number of configurations are different. Is there a way to simplify this configuration?

Spring providesBean inheritanceTo solve this problem. Spring can configure a bean template for these beans first, and configure the same configuration information in these beans as bean templates, because the spring container does not need to create bean template instances, therefore, this bean template is usually configured as an abstract bean.

After you configure most of the same information as the bean template, you can configure the actual bean instance as the sub-bean of the bean template. Sub-bean definitions can inherit the configuration information such as implementation class, constructor parameters, and attribute values from the parent bean. In addition, the sub-bean configuration can add new configuration information, the new configuration information can overwrite the definition of the parent bean.

Child beans cannot inherit the following attributes from the parent Bean: depends-on, autowire, Singleton, scope, and lazy-init. These attributes will always be obtained from the Child bean definition or take the default value.

By specifying a <bean.../> elementParent attributesYou can specify that the bean is a child bean, and the parent attribute specifies the ID of the parent bean inherited by the bean.

Axe. Java:

 
Public interface axe {Public String chop ();}
 

Steelaxe. Java:

 
Public class steelaxe implements axe {@ overridepublic string chop () {return "cutting firewood really fast";} public steelaxe () {system. out. println ("Spring instantiation dependent Bean: steelaxe instance... ");}}
 

Stoneaxe. Java:

 
Public class stoneaxe implements axe {@ overridepublic string chop () {return "";} public stoneaxe () {system. out. println ("Spring instantiation dependent Bean: stoneaxe instance... ");}}
 

Person. Java:

 
Public interface person {public void useaxe ();}
 

Chinese. Java:

Public class Chinese implements person {private axe; Public void setaxe (axe) {system. out. println ("Spring executes dependency injection... "); this. AXE = axe;} Public Chinese () {system. out. println ("Spring instantiation of the main Bean: Chinese instance... ") ;}@ overridepublic void useaxe () {system. out. println (axe. chop ());}}
 

Bean. XML Core Configuration:

 
<Bean id = "steelaxe" class = "com. bean. steelaxe "/> <bean id =" stoneaxe "class =" com. bean. stoneaxe "/> <bean id =" chinesetemplate "class =" com. bean. chinese "abstract =" true "> <property name =" Axe "ref =" steelaxe "/> </bean> <bean id =" Chinese "parent =" chinesetemplate "/>
 

Test. Java:

Public class test {public static void main (string [] ARGs) {applicationcontext CTX = new classpathxmlapplicationcontext ("bean. XML "); person P = (person) CTX. getbean ("Chinese"); p. useaxe ();}}
 

Run test. Java and the console outputs:

Child beans inherit the implementation class, dependency, and other configuration information from the parent bean. In fact, the Child bean can overwrite the configuration information of the parent Bean:

 
<Bean id = "steelaxe" class = "com. bean. steelaxe "/> <bean id =" stoneaxe "class =" com. bean. stoneaxe "/> <bean id =" chinesetemplate "class =" com. bean. chinese "abstract =" true "> <property name =" Axe "ref =" steelaxe "/> </bean> <bean id =" Chinese "parent =" chinesetemplate "> <property name = "Axe" ref = "stoneaxe"/> </bean>
 

Run test. Java again, and the console outputs: