Breaking Java law: No need to create objects-Ioc container revolution

We know that there is a law in the Basic Java tutorial that tells us that all objects must be created; or: they must be created before they are used, but now we don't have to follow this law, we can get an object from the Ioc container and use it directly without creating them in advance. This kind of change is just like we don't need to consider object destruction; Because Java's garbage collection mechanism helps us achieve object destruction; now we don't need to consider object creation, the creation and destruction of objects do not need to be considered, which has a huge impact on programming.

Starting from a simple example, we have a common class B Code as follows:
public class B implements BI{
　　　　 AInfterface a;

　　　　 public B(AInfterface a){

　　　　　　 this.a = a

　　　　 }

　　　　 public void invoke(){

　　　　　　 /** ...*/

　　　　 }

}
There are two ways to use B:

Call Method for a common non-Ioc container:
BI B = new B (new A (); // instances such as A need to be generated before B is generated
B. invoke ();

Revolutionary call methods using Ioc containers (Jdon framework:

　　BI b = (BI) WebAppUtil.getService(“b”);
　　 b. invoke();
Important differences between the above two methods:
The former needs to take care of the instantiation of Class A in Class B. If Class B calls more than Class A, and more other classes such as C/D/E, when using class B, you also need to study the creation of other classes. If the classes C/D/E are not compiled by yourself, you also need to read their API descriptions, how should they be created? Are New, factory, or single-State calls used?

At this moment, you will sigh: Wow, are there any mistakes? I just spent so much time and energy using a small method in Class B?

When we use the second method, we don't need to spend A lot of time thinking about the creation of A/C/D/E class.

With the Ioc container, you no longer have to do these rigid and stupid jobs. We just need to capture a class from the ioc container and then use them directly.

Of course, before using it, we need to make a simple configuration to tell the ioc container all the classes you need in the future. For example, configure jdonframework. xml in the ioc container of the Jdon framework as follows:
<app>
　　<services>
　　　　<pojoService name="b" class="test.B"/>
　　　　<pojoService name="a" class="test.A"/>
　　　　<pojoService name="c" class="test.C"/>

　　</services>
</app>

Note:: Although class B code calls Class A (or even other classes such as C), we do not need to consider this call relationship in the configuration. Therefore, we do not need to consider the call relationships of other classes in Class B throughout the entire process; this is very time-saving and labor-saving. Especially if the project is large, there are many JavaBeans, and many people coordinate the development, this method is very helpful for improving development efficiency and reducing the error rate.

If there are many classes in your project, the call relationship is complex, and the call relationship may change at any time, using the Ioc container that does not need to take care of the call relationship is undoubtedly the first choice to reduce the development burden.

Another famous Implementation of ioc container is the Spring framework. However, in the Spring configuration file applicationContext. xml, we must consider the above call relationship:

<Bean id = "B" class = "test. B">
<Property name = "a"> <ref bean = "a"/> </property> <! -- Call relationship must be specified -->
....
</Bean>
<Bean id = "a" class = "test. A">
<Bean id = "c" class = "test. C">
Therefore, from the above comparison, from the perspective of project development efficiency, the actual configuration efficiency of the Jdon framework based on PiocContainer is undoubtedly higher than that of the Spring framework.

At the same time, it can be said that the Jdon framework based on PiocContainer fully realizes the revolutionary advantage of Ioc containers: It subverts the Basic Java language law of "must be created before using objects.

[Back to homepage]