主要内容：

Dependency Injection

The concept of dependency injection (DI), objects are given their dependencies at construction time, is one of the foundations of the Spring Framework. You have also probably heard of Inversion of Control (IoC). IoC is a broader, more general concept that can be addressed in different ways. IoC lets developers decouple and focus on what is important for a given part of an enterprise application, but without having to think about what other parts of the system do. Programming to interfaces is one way to think about decoupling.

Almost every enterprise application consists of multiple components that need to work together. In the early days of Java enterprise development, we simply put all the logic of constructing those objects (and the objects those objects needed) in the constructor (see Listing 2-1). At first sight, there is nothing wrong with that approach; however, as time progressed, object construction became slow, and objects had a lot of knowledge they shouldn’t have had (see the Single Responsibility Principle). Those classes became hard to maintain, and they were also quite hard to unit and/or integration test.

The class from Listing 2-1 programs to interfaces, but it still needs to know about the concrete implementation of an interface simply to do object construction. Applying IoC by decoupling the construction logic (collaborating objects) makes the application easier to maintain and increases testability. There are seven ways to decouple this dependency construction logic:

1. Factory pattern

2. Service locator pattern

3. Dependency injection

a. Constructor based

b. Setter based

c. Interface based

d. Annotation driven

4. Contextualized lookup

When using the factory pattern, service locator pattern, or contextualized lookup, the class that needs the dependencies still has some knowledge about how to obtain the dependencies. This can make things easier to maintain, but it can still be hard to test. Listing 2-2 shows a contextualized lookup from JNDI (Java Naming and Directory Interface). The constructor code would need to know how to do the lookup and handle exceptions.

The immediately preceding code isn’t particularly clean; for example, imagine if there were multiple dependencies from different contexts. The code would quickly become messy and increasingly hard, if not impossible, to unit test (see Chapter 9 for more information on testing).