You’re going for something akin to (but not similar) Spring’s ApplicationContextAware, where you pass ApplicationContext (which is a BeanFactory) via a setter, so it later can get beans it needs.

Generally it is a bad idea, if you only need to inject dependencies:

• It is not explicit about dependencies it uses. So, it is actually harder to mock, not easier, because you’re not sure what needs to be mocked unless you look into the whole code of a class and probably the whole code of its’ super- and subclasses, if inheritance happens.
• It is not type safe if you query dependencies by string keys, with all negative consequences of that. However, if you say you’ll have specific interfaces to deal with that (like UserRepositoryFactory which has a method like getUserRepository, I guess), it will be type safe, but I don’t see the benefit in this solution, because it seems much easier to just inject dependencies without medium getter/wrapper/injector-objects. I think it would be just duplication of DI functionality.

If I would make a plugin system, I would go with “stupid” plugins, which just implement some SomethingPlugin interface, and expect it’s dependencies to be injected (via constructor or setters, which doesn’t really matter) by the system, without any prior knowledge of anything outside.

Example:

public class UserRatingPlugin implements GenericPlugin,
        UserRepositoryAwarePlugin, PostResositoryAwarePlugin {

    // here are dependencies
    private UserRepository userRepository;
    private PostRepository postRepository

    @Override // from UserRepositoryAwarePlugin
    public void setUserRepository(UserRepository ur) {
        userRepository = ur;
    }

    @Override // from PostResositoryAwarePlugin
    public void setPostRepository(PostRepository pr) {
        postRepository = pr;
    }

    @Override // from GenericPlugin
    // this should be required to make this class a plugin
    public void doPluginMagic() { /* ... */ }
}

Then you register this plugin (via config file, I imagine), then somewhere in a “system level” code you instantiate this class, set dependencies (this part can be automated by Spring’s or similar DI-container) and invoke doPluginMagic().

This way you still have small specific interfaces, but now as parts of a plugin API, which I think simplifies the whole thing. You can see what plugin can access by just looking on its’ type declaration, and no additional “factories” have to be crafted.

Your dependency lookup looks very similar to service locator pattern, except that often, service locator is static.

The benefits of such dependency lookup when compared to ordinary dependency injection are that:

• You won’t find constructors which take dozens of (often mandatory) arguments if they need many dependencies. This makes your code shorter and easier to read and write.

• You don’t need to change the definition of the constructor when the object needs to rely on an additional dependency (or don’t need a previously used dependency). This means less code changes over time.

There is however a drawback:

• The dependencies are out of control. When dependencies are injected through the constructor, by looking at the constructor, you immediately know which dependencies the class needs. If the only thing there is a lookup (or a service locator), you only know that the class relies on one to N dependencies, with no additional information.

  This also makes it difficult to use those classes. Imagine you’re in a context of a unit test. Which objects, in the lookup, should be mocked? The problem exists already for dependency injection (since the tested method don’t necessarily have to use every dependency requested by the class), but with a lookup, it becomes larger, with more dependencies which can be potentially used.

  Pass-through (that is when a class A requests a dependency in order to pass it to another class B it calls) can make this task even worse, since you have no visibility on which dependencies are used by the class B if you pass the lookup to it.