Dependency Injection and AOP Brief (vi)--string request mode.

2. Request mode for dependent injection objects

In the previous section we discussed several methods for declaring injection points, which are mainly about how to locate the required identifiers on the injection point. Basically, we can request a dependent object with a string as an identifier, or use a full class name (FQCN) as an identifier to request a dependent object, or a pattern mixed with both. Let's go through this in turn.

2.1. String Request mode

As the name implies, the string request pattern, which relies on the injection framework, binds a dependency to the specified string and then loads it into a dependent injection container. Through this string, the relying person requests the required dependencies to the container. Both seam and spring are typical frameworks that are based on the string request pattern.

In such a pattern, the dependent identifiers that are managed in a container are defined by a string, such as when we define the bank and Depositbook dependencies, respectively, by binding them to both the "bank" and "Depositbook" strings.

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

Then for the dependency class, the container will automatically return instances of BANKICBC and DEPOSITBOOKICBC to the dependents whenever it is declared on the injection point that the request identifier string is dependent on "bank" or "Depositbook". Note Earlier we also mentioned that the seam framework in the @in injection point default is considered to be the request with the member variable name of the dependency, so the following two kinds of request relies on the same wording:

@In//Request identifier for "bank" dependent object private Bank BA nk  ,     @In//Request identifier for "Depositbook" dependent object   private Depositbook depositbook;

@In (" bank ")//Request Identifier" Bank "of the dependent object private bank;       @In ("Depositbook")//Request Identifier "Depositbook" for the dependent object   private Depositbook depositbook;

Although seam and spring adopt a pattern defined by a pure string identifier, there is a big weakness in this pattern: it violates the "type safety (Type-safe)" principle, which means that a dependency object that is not expected by the dependency class may be mistakenly injected. Imagine a scenario where a developer mistakenly writes "bank" as "bak" while developing the depositor class and defining the dependencies it needs, while other developers are registering a dependency on the container with an identifier of "bak".

@In ("bak")//The dependent object with the identifier "BAK" was requested incorrectly Private Bank Bank; @Name ("bak")//other developers just registered a "bak" dependency in the container Public class Bak {//...}

At this point the Java compiler compiler does not have any error message, because @in is a runtime annotation, according to the JAVA5 annotation principle, runtime annotations at compile time is almost equivalent to a comment line is ignored by the compiler, only to the runtime will be resolved by the code snippet. Therefore, whether the developer is defined as @in ("bak") or @in ("bakxxx"), and so on, will not have any effect on the compilation of the code. In this example, while the developer mistakenly relies on the "Bak" dependency request, it compiles the application normally and then throws a ClassCastException exception when running the application, which requires the developer to take the effort to troubleshoot the error.

Of course, if the situation is relatively simple, you might be able to quickly get rid of the bug, but there are more terrible things: imagine that the Bak class and the Bank class is a parent-child class with inheritance, then even at run time will not throw classcastexception exception, Because dependencies can be correctly cast and set to the injection point, it is possible that the application will be executed very deep before the unexpected bug, it is difficult to troubleshoot errors.

There is, of course, another case where there is no "bak" dependency in the container. At this point the code at the point where the injection points are declared without special qualification, the container is likely to set a null object to the injection point, and still only throws the NullPointerException exception at run time. The NPE exception is perhaps the least common exception that Java developers would like to see because of its poor self-descriptive nature, making it often difficult for developers to locate the error.

Dependency Injection and AOP Brief (vi)--string request mode.