Introduction to Inversion Of Control (IOC)

IOC Definition (based on Wikipedia)  Consider the way in which an object obtains references to its dependencies.  Often done by a lookup method.  This approach has the disadvantage that an explicit dependence is introduced on a particular lookup mechanism, so the caller is dependent on a particular environment as well as on the object it obtains.  With inversion of control the object is passed its dependencies through constructor arguments (constructor injection) or after construction through setter methods (setter injection).  Also called 'dependency injection‘ (DI) since the dependences of an object are 'injected' into it.

IOC Advantages  IOC/DI decouples objects from specific lookup mechanisms and implementations of the objects it depends on.  Greater flexibility is obtained for production applications as well as for testing.  In particular, dependencies on a particular deployment environment can be removed from the code, making it much easier to test functionality in a simple standalone environment.  One consequence - it becomes faster and easier to test; quality of the software is improved.

Dependency Injection Styles  Setter Injection  Setters are provided in the JavaBean style using standard property naming conventions.  This style is used for the examples in this presentation.  Constructor Injection  Parameters to constructors are provided, and set during object creation by the IOC container, with possible post-construction invocation of a configurable initialization method.  There are some concerns (handling of many or optional parameters) and dangers (possible circular dependencies) in using this DI style.  Interface Injection  Objects implement dedicated interfaces that provide them with objects from which they can look up dependencies (other services).  This style creates its own dependencies, is quite involved to set up and maintain, and is not generally recommended.

IOC Support in the Spring Framework

Example – Application Configuration  Application – A Named Entity Resolution service will be provided by a configured set of components  One approach is to provide a factory and factory methods that provide a configured component bundle.  A second approach is to design the components as JavaBeans, provide setters for configuration dependencies, and use an IOC container to allow external configuration.

UML Diagram

Configuration Alternatives  ResolutionManager  IResolver (ResolverBasic, ResolverMaximized)  IBlockStrategy (LnameZipBlockStrategy, SsnBlockStrategy, …)  IMatchStrategy (MatchStrategyMaximized, …)  ErdSvmClassifier (not shown in UML diagram) (ErdSvmLightClassifier, ErdLibSvmClassifier, …)

Spring XML IOC Configuration  File: mockTestConfig1.xml 

Programmatic Usage  private static final String TEST_CONFIG_PATH_1 = "src/com/thomson/research/erd/engine/config/mockTestConfig1.xml";  private static final String SPRING_RESOLUTION_MANAGER_ID = "resolutionManager"; …  String curDir = System.getProperty("user.dir");  String fullConfigPath = curDir + "/" + TEST_CONFIG_PATH_1;  XmlBeanFactory factory = new XmlBeanFactory(new FileSystemResource(  fullConfigPath));  ResolutionManager rm = (ResolutionManager) factory .getBean(SPRING_RESOLUTION_MANAGER_ID); …   // Execute/test the resolve(...) method.  List emList = rm.resolve(permutationList); Configuration information is read by framework here. Configuration is applied here. Configured ResolutionManager is used here.

For More Information…   