Questioning Dependency Injection through name-lookup

I find myself struggling with the fuzz around the concept of string-based 'Service Locators'.

For starters, IoC is great, and programming to interfaces is the way to go. But I fail to see where the big benefit lies in the yellow-pages pattern used here, apart from compilation-less reconfigurability .

Application code will use a (Spring) container to retrieve objects from. Now that's nice: since the code needs to know only th开发者_如何学运维e needed interface (to cast to), the Spring container interface, and the name of the needed object, a lot of coupling is removed.

public void foo(){
   ((MyInterface) locator.get("the/object/I/need")).callMe();
}

Where, of course, the locator can be populated with a gazillion of objects of all kind of Object derivatives.

But I'm a bit puzzled by the fact that the 'flexibility' of retrieving an object by name actually hides the dependency in a type-unsafe, lookup-unsafe manner: where my compiler used to check the presence of a requested object member, and it's type, now all of that is postponed to the runtime phase.

The simplest, functionally allright, pattern I could think of is a giant, application wide struct like object:

public class YellowPages  {
    public MyInterface the_object_i_need;
    public YourInterface the_object_you_need;
    ....
}

// context population (no xml... is that bad?)
YellowPages locator = new YellowPages();
locator.the_object_i_need=new MyImpl("xyx",true),
locator.the_object_you_need=new YourImpl(1,2,3)


public void foo(){
   locator.the_object_i_need.callMe(); // type-safe, lookup-safe
}

Would there be a way/pattern/framework to ask the compiler to resolve the requested object, and check whether it's type is ok? Are there DI frameworks that also do that?

Many thanks

What you are describing is an anti-pattern, plain and simple. Dependency injection (done via the constructor if possible) is the preferred way to do Inversion of Control. Older articles on IOC talk about service location as a viable way to implement the pattern, but you'd be hard pressed to find anyone advocating this in more recent writings.

You hit the nail on the head with this statement:

But I'm a bit puzzled by the fact that the 'flexibility' of retrieving an object by name actually hides the dependency in a type-unsafe, lookup-unsafe manner:

Most modern DI frameworks can get around the type-unsafe part, but they do hide the dependency by making it implicit instead of explicit.

Good article on this topic:

Service Locator is an Anti-Pattern

Spring is the only DI framework that I've used, so I can't speak for others, but even though Spring give you the ability to request an object by its name in your code, you don't have to get your Spring beans by name -- in fact, if you do, you're not really capitalizing on the "I" (inversion) in IOC.

The whole principle behind Spring/DI is that your objects shouldn't be asking for a particular object -- it should just have whatever objects it needs handed to it by the IOC container. The distinction is subtle, but it's there. The former approach would resemble the code that you pasted:

public void foo(){
   ((MyInterface) locator.get("the/object/I/need")).callMe();
}

The latter approach, by contrast, doesn't depend on any service locator, nor does it depend on the "name" of the object that it wants:

private ObjectINeed objectINeed;

public void setObjectINeed(ObjectINeed objectINeed) {
    this.objectINeed = objectINeed;
}

public void foo(){
   objectINeed.callMe();
}

It's the IOC container that calls the setObjectINeed() method. DI is definitely tackles the same problem as the service locator pattern, but it goes that extra step towards getting rid of the dependency on your service locator class.