Platinum Partner
java,frameworks,dependency injection

Which Features of Dependency Injection Really Matter

I've spent last four years on developing applications that was build on top of the Inversion of Control pattern. My experience with IoC or more precisely Dependency Injection is biased by using of Spring framework, but it doesn't matter because features I'll be talking later coming from real application use cases.

Feature: delegated instantiation of a managed object

Why: In some cases IoC container has to be able delegate instantiation of a managed object to some else. An object model may introduce some kind of Factory or Factory method and IoC container should respect it. There are situation when the code cannot be refactored e.g. 3rd party libraries, legacy code.

Feature: collecting of managed objects

Why: Need for reducing tightly coupling between API provider and API consumer. This is useful in situation when an API defines an extension/integration point and implementations are collected in runtime based on classpath. See following self-descriptive code as example of intended feature.

public interface ServiceProvider {
}

@Service
public class MyProviderA implements ServiceProvider {
}

@Service
public class MyProviderA implements ServiceProvider {
}

@Service
public class ServiceProviderRegistry {
   @Autowired
   private List providers   

} 

public class ServiceProviderRegistryTest {
    @Autowired
    private ServiceProviderRegistry registry;

    @Test
    public void test() {
        assertThat(registry.getProviders().size(), is(2));
    }
}

Feature: visibility scopes

Why: Not all managed objects are public in terms of visibility for others. Let suppose there is a component solving some business case. This component internally uses dependency injection, but only one central facade is exposed for participation in DI to other, internally managed objects are not visible for DI outside of component. It's like something between Java visibility modificators and exposing some service in OSGi, but on level of DI. Spring framework support it by concept of hierarchical bean factories and inner beans.

Feature: adaptable dependency resolving

Why: The code runs in different environments (server, tests, local/desktop), but the dependencies are same. Lets take the datasource abstraction as an example. The code depends on datasource (javax.sql.Datasource), so there are various configuration for environments (e.g. JNDI lookup in application server). IoC container is parameterized (programaticcaly or via system properties) by target environment. According to target environment an appropriate datasource definition is taken.

Conclusion

I got constant feeling that DI introduced in EJB 3.1 still lacks these features. I don't know if it's only my opinion, but there should be one specialized JSR that brings definitely DI to Java SE. Related JSRs in Java EE should only adopt/integrate DI to application server environment.

{{ tag }}, {{tag}},

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}
{{ parent.authors[0].realName || parent.author}}

{{ parent.authors[0].tagline || parent.tagline }}

{{ parent.views }} ViewsClicks
Tweet

{{parent.nComments}}