Spring note--5. Deep understanding of the beans in the container

Most of the work of the spring framework is the management of beans, including the management of the bean's life cycle and the use of the bean inheritance function.

Abstract bean and child bean

To prevent too many very similar beans from appearing in XML, we use abstract beans to extract common information and mark it with the abstract attribute as true. It cannot be instantiated, meaning is simply inherited and is a template. A child bean can inherit an abstract bean's implementation class, constructor parameters, and property configuration information. The child bean can either add new information or overwrite the parent bean. The child bean specifies the name of the parent bean by using the Parent property. In contrast to Java inheritance, bean-inherited bean types can be completely ignorant of the relationship between instances, and inherit attribute parameter values.

<bean id= "Steelaxe" class= "Com.cm.SteelAxe"/><bean id= "father" class= "Com.cm.Person" abstract= "true" > <property name= "name" value= "a Axe"/><property name= "Axe" ref= "Stellaxe"/></bean><bean id= " Chinese "parent=" father "/>

Factory beans in the container

In the previous section we said that static plants and power plants do not need to implement or inherit anything. The factory bean here needs to implement the Factorybean interface, which is a special kind of bean. This interface is the standard interface for factory beans. If you use Getbean to return a factory bean, it is not the instance that is returned, but its product. The method of producing the product is its GetObject method.

Public class myfactory implements factorybean<object> {private string  targetclass;public string gettargetclass ()  {return targetclass;} Public void settargetclass (String targetclass)  {this.targetclass = targetclass;} Public string gettargetfield ()  {return targetfield;} Public void settargetfield (String targetfield)  {this.targetfield = targetfield;} private string targetfield; @Overridepublic  object getobject ()  throws exception  {// TODO Auto-generated method stubClass<?> clazz =  Class.forName (Targetclass); Java.lang.reflect.field field = clazz.getfield (TargetField); return  field.get (null);} @Overridepublic  class<?> getobjecttype ()  {// todo auto-generated method  stubreturn object.class;} @Overridepublic  boolean&nbsP;issingleton ()  {// todo auto-generated method stubreturn false;}} 

As shown in the code above, two properties are configured in XML, and the GetObject method can return a specific instance. The spring schema will scan all the beans at the beginning, and if it finds out which Bean implements the Factorybean interface, then, well, the schema will use its GetObject method to get an instance (not actually understood as an instance, Instead, the arbitrary return value of that method is stored in the container as an instance of the corresponding ID, not as an instance of the class directly. When using Ctx.getbean, the generated instance is returned directly with the ID. If the name is added to a &, the Factorybean itself is returned directly.

Get the ID of the bean itself

The configuration ID of the bean can be predicted in advance through the Beannameaware interface. The name parameter of the setbeanname of this interface is the ID of the bean, which is actually a string, which can be understood as either an ID or a name.

Import Org.springframework.beans.factory.beannameaware;public class Gethisid implements Beannameaware {private String beanname; @Overridepublic void Setbeanname (String arg0) {//TODO auto-generated method stubthis.beanname = arg0;} public void info () {System.out.println (beanname);}}

Spring again to automatically detect, very tired ah, if discovered which Bean implements the Beannameaware interface, then good, after creating this bean, immediately call the Setbeanname method to save the ID. The so-called Get ID refers to the member variables that are taken out of the container and stored in a bean. However, there are few opportunities to use the bean's configuration ID.

Force initialization of beans

When the dependencies in some beans are particularly complex, we can use the Depends-on property to make the bean that it depends on, so that the bean is instantiated first, and then the bean is processed to prevent errors. If the dependent bean has not been instantiated, it is wrong.

This article from "Fingertip Light Fly" blog, declined reprint!

Spring note--5. Deep understanding of beans in a container