Why should we not use look up instead of dependency injection?

Question

Is there any good reason to not look up an object in application context instead of "suppose" a dependency was injected? Ex:

public Dependency getDependency(){
     if (dependency  == null){
        dependency = (Dependency) applicationContext.getBean("dependency");
     }
     return dependency;
}

Debatable arguments

Polluting object with Spring specific object

Some people could complain that using application context will bind the implementation with Spring stuffs. BUT, it could be trivially solved creating a indirection to applicationContext. Ok... let me exemplify:

public Dependency getDependency(){
     if (dependency  == null){
        dependency = (Dependency) serviceLocator.getBean("dependency");
     }
     return dependency;
}

Hard to change implementation

First, it (the dependency object) could be easily changed in application context. But, even easier a mock could be insert directly using the usual mutator:

public void setDependency(Dependency dep){
     this.dependency = dep;
}

Historical question

Long time ago, everybody in Java world was using Service Locator (in a directory service by a technology called JNDI) to have a interchangeable object infrastructure. We could bind in the directory service three kind of objects: serializable data, reference or Dircontext. It would additionally allow you to look up objects in distributed environment.

Then, we have the Spring revolution and now DI (Dependency injection) is used most of the cases.

However, the service locator pattern was not prohibited by Spring. For instance, using ApplicationContext allow us to look up the beans in a service locator way. We could think that the Spring framework provides a big factory of objects with a centralized configuration, the dependency injection facility but also a directory of services that could be easily handle. The last part has been almost forgotten.

Related Question

Why is Spring's ApplicationContext.getBean considered bad?

I am not considering that because those answers although edifying , they are not enlightening the points raise above.

Answer 1

My personal view on this. ease of use of DI via annotation versus having to get the bean via applicationContext. But at the end of the day, I think that the main difference is how the dependencies are located. Service Location entails a client code request for the related specific dependency , whereas using dependency injection the container creates all of objects and injects those dependency as constructor parameters. Frankly at the end of the day both are feasible, but consider this: as far as I know JNDI lookup are pretty expensive in terms of performance so ultimately you are advised to cache them.

Answer 2

Injected service components are simpler than ones that use service locators, and simpler is usually better engineering. Beans that use dependency injection are just regular old Java objects that (sometimes) happen to have @Inject annotated on a constructor (Spring JavaConfig beans may not even need any of that). The bean has no need to manually interface with lookup code, and if you need to alter the dependency that you're passing to it (say, so that you can inject a mock), a bean that's managing its own dependencies will need a lot more infrastructure just to get built.