IoC Introduction

Introduction to IoC

See IoC example on why to use IoC with an example in Pico. Changes to this example to use it with Spring are in Spring example.

Example for conventional lookup (e.g. with JNDI in EJBs):

public class Foo {
   public Foo() {
   }
   public String service() {
      return BarManager.lookup("myBar").doSomething();
   }
}

Example of IoC 3:

public class Foo {
   private Bar bar;
   public Foo(Bar bar) {
      this.bar = bar;
   }
   public String service() {
      return bar.doSomething();
   }
}

Types

• Method-based (M) IoC : Pass dependent components to the component with every method call
• Interface-based (I) IoC (Type 1): Uses Interfaces like Serviceable, Configurable etc. for declaring dependencies
• Setter-based (S) IoC (Type 2): Uses setters for setting dependent components
• Constructor-based (C) IoC (Type 3): Uses constructors for declaring dependencies

Example Method based IoC :

public class Foo {
   public Foo() {  
   }
   public String service(Bar bar) {
      return bar.doSomething();
   }
}

Example of IoC 1:

public class Foo implements Barable {
   public Foo() {  
   }
   public void doBar(BarManager bm) {
     Bar bar = (Bar) bm.lookup("myBar");
     bar.service();
   }
}

Example of IoC 2:

public class Foo {
   private Bar bar;
   public Foo() {  
   }
   public void setBar(Bar bar) {
      this.bar=bar;
   }
   public String service() {
      return bar.doSomething();
   }
}

Disadvantages

• You declare your dependencies, some magic happens and they are resolved. Magic makes source code harder to understand than lookups (because they are implicit not explicit)

Advantages

• If you use singletons or lookups your unit tests are difficult to write (Just see all those special J2EE unit frameworks). With lookups you usually have to implement a registry that supplies MockObjects. If your lookups are static methods replacing them with MockObjects is even more difficult. With lookups you might have to do this (if you can control the registry, which most of the time is impossible or at least hard to do):

// What if you can't change the created class
// in your singleton or registry? Do you need to rewrite
// the whole JNDI lookup classes?
BarManager.setBarClass("myBar", MockBar.class);
Foo foo = new Foo();
assertEquals("ping", foo.service());

IoC is more JUnit test friendly than lookups. With Type-3 IoC you just do:

Foo foo = new Foo(new MockBar());
assertEquals("ping", foo.service());

With Type-2 this would be:

Foo foo = new Foo();
foo.setBar(new MockBar());
assertEquals("ping", foo.service());

• No external dependecies. You can develop and test your components in the enviroment you like, you do not need to use a special deployment enviroment for your components during development (like with JNDI / EJB)
• Easier to reuse and easy exchangeable between different IoC containers. Either implement simple wrappers or add setters and interfaces to use components from e.g. Pico in Avalon and Spring

Advantages of Type-2

• Beans are well understood by Java developers, beans exist in most projects
• More easily satisfies optional dependencies

Disadvantages of Type-2

• Dependencies can be seen from the code. What are dependencies and what are normal setters and getters? Additional setters and getters make code more noisy
• Needs some XML (or other) meta data which makes understanding code more difficult from looking at it

Advantages of Type-3

• Stronger contract between components
• Components cannot exist in "limbo" state between creation and when they can be used. This is more defensive

Disadvantages of Type-3

• You may need your constructors (I do not :-)
• Inheritance can become more difficult.