Dependency Injection and AOP Brief (III.)--the principle of dependency injection

3. "Dependency Injection" debut

So many good it engineers started to come up with a lighter, more testable and maintainable design pattern--IOC mode. The IoC, the abbreviation for inversion of control, is referred to as the "inversion of controls" in Chinese. As to why there is such a strange-looking name, we will explain it later. 2004 famous software engineering scholar and engineer Martin Fowler in his thesis "Inversion Ofcontrol Containers and the Dependency injection pattern" The change of IOC to Dependencyinjection, from which the dependency injection mode becomes the mainstream design idea that realizes the loose coupling between components.

3.1. Principle of Dependency Injection

So what will happen to our development model when we apply dependency injection? Let's take a look at just the example. The following code is the Depositor depositor class after applying the dependency injection:

Public class depositor { @In private Bank bank; @In logo Here is an injection point @In private depositbook Depositbook; @In logo Here is an injection point Public Cash Withdraw (BigDecimal amount) { return Bank.withdraw (Depositbook, amount); } }

As you can see, this depositor class is almost the simplest class that we have ever defined, which has no process of initializing dependencies! The only difference is that when you define a dependent member variable, you add a JavaSE5 standard annotation-@In. Here @in annotations are one of the annotations provided by JBoss Seam, one of the mainstream dependency injection frameworks, for the same use of other dependency injection frameworks, such as Springframework, which provides @autowired annotations equivalent to seam @in,google The Guice framework provides a @in that @inject annotations are equivalent to seam. On the topic of dependency Injection Framework we'll do the introduction later, and now let's take a look at the implementation of dependency injection in the dependency injection framework, which we'll cover with the seam framework as an example.

The core of a dependency injection framework is a dependency injection container, often referred to as an IOC container or called injector. Its role is to manage all the dependencies that are registered to them and to provide those dependencies to the dependent relying on the request. When it comes to this, one might ask, what is the difference between this dependency injection container and the Servicelocator container mentioned in the previous section, which is not a container for managing dependent objects? The answer is very different. The difference is that the first to rely on the injection container is extremely lightweight and controllable, the dependent objects registered in it can be easily determined by the developer of their identifiers and registration process, and can be easily put into the unit test environment, and then rely on injection container not only for developers to manage the dependency, More importantly, it can automatically manage the scope and lifecycle of dependent objects as needed, as well as enhance the behavior of dependent objects (that is, AOP), which we'll cover in more detail later in the chapter.

Back to just the example:

@In private Bank bank; @In logo Here is an injection point @In private depositbook Depositbook; @In logo Here is an injection point

The place where @in is labeled is called the "injection Point" (Injectionpoint), and the point of injection is to tell the dependency injection container "here, please give me the dependent object!" ", that is, @in makes a request to the dependency injection container, and then the container uses the Java reflection mechanism to set the object it is holding to the injection point, which completes a dependency injection.

If the dependent objects requested by the @in injection point are dependent on themselves, then the dependency injection container will also set up this "dependent dependency" in the same way, that is, the dependency injection container will help the developer build a complete dependency graph and finally provide a fully initialized dependent object to the relying person.

Strictly speaking, dependency injection also has many patterns, and when it comes to situations such as cyclic dependency patterns, partial dependency patterns, and so on, the dependency injection container does not provide the "fully initialized" object to the relying person. These situations are special, and the various dependency injection frameworks have different solutions, which we will not discuss in detail here.

As for how to register a dependency into a container, each dependency injection framework has different ways of using it, but basically it's pretty much the same, and here we look at a code that takes the seam framework as an example:

@Name ("bank") Public class BANKICBC implements Bank {//...} @Name ("Depositbook") Public class DEPOSITBOOKICBC implements Depositbook {//...}

The class @name labeled here represents that the class needs to be registered as a dependent object in the seam container, which is completed during the application startup process. These two dependencies, which are then registered to the seam container, can be provided to the dependent at the time of the request. In addition to the @name annotation in the seam framework, you can also declare a component class that needs to be registered in the container by using the <component> tag configuration of the XML file. If you are using the spring framework, you can declare component classes by @component or XML <bean> tags, and the Guice framework is done through the binding of module, In summary, various dependency injection frameworks provide a convenient way to register dependencies with their containers.

Note that annotations, such as the @in of the preceding example, are not the only way to define injection points. The general Dependency Injection framework also provides an API and XML configuration to declare the injection point. For example, in the way of APIs, when using the seam framework, call its Component#getinstance API, or invoke its Beanfactory#getbean API when using the spring framework, or call its injector# when using Guice GetInstance API, etc., is a way to declare the injection point. For example, in XML configuration, both the seam and spring frameworks provide <property> tags to declare the injection points in the dependency class.

We can see that after applying the idea of dependency injection, our Depositor class can appear in our code base in one of the simplest gestures. For future maintenance, the Depositor class itself will not be affected by any change in the construction method of the two dependent classes of the bank and Depositbook. And in the unit test, we can easily replace the actual dependency with the mock class. Simply bind the mock class to the same identifier, and the container will provide the mock class to the relying person when the dependent person requests the dependency. For example:

@Name ("bank")//using the same identifier "bank" Public class Bankmock implements Bank {//This is a mock dependency class} @Name ("Depositbook")//using the same identifier "Depositbook" Public class Depositbookmock implements Depositbook {//This is a mock dependency class}

Dependency Injection and AOP Brief (III.)--the principle of dependency injection