Inversion of ControlWhat is this all about ? Well it is a design pattern that also sometimes called the Hollywood Patten ("Don't call us we'll call you") or the Chain of Command pattern. Simply put, a component does not go off and get other components that it needs on instantiation, it instead declares them to its boss, and the boss supplies them. BasicsWithout worrying about the generationos of IoC that let us arrive at the PicoContainer design, Here is the simplest possible IoC component : public interface Apple { // methods } public interface Orange { // methods } public class AppleImpl implements Apple { private Orange orange; public AppleImpl(Orange orange) { this.orange = orange; } // other methods } Here are some common smells that lead you refactor to IoC public class AppleImpl implements Apple{ private Orange orange; public Apple() { this.orange = OrangeImpl.getOrange(); } // other methods } The problem is that you are tied to OrangleImpl for provision of Orange services. Simply put, the above cannot be a component, it's an application. All hard coded. Not reusable. It is going to be very difficult to have multiple instances in the same classloader with different assembly. Here are some other smells along the same line : public class AppleImpl implements Apple { private static Orange orange = OrangeFactory.getOrange(); public Apple() { } // other methods } ConfigurationSometimes we see configuration like so ... public class BigFatComponent { String config01; String config02; public BigFatComponent() { ResourceFactory resources = new ResourceFactory(new File("mycomp.properties")); config01 = resources.get("config01"); config02 = resources.get("config02"); } // other methods } In the IoC design, it might be better to see the following for simple designs : public class BigFatComponent { String config01; String config02; public BigFatComponent(String config01, String config02) { this.config01 = config01; this.config02 = config02; } // other methods } Or this for more complex ones .. public interface BigFatComponentConfig { void getConfig01(); void getConfig02(); } public class BigFatComponent { String config01; String config02; public BigFatComponent(BigFatComponentConfig config) { this.config01 = config.getConfig01(); this.config02 = config.getConfig02(); } // other methods } Where there could be many design for the implementation of BigFatComponentConfig:
It is the deployers or container makers choice. Of course, in all of these discussuions, it is important to point out that Logging is a common exception to the IoC rule. Apache has two static logging frameworks that are in common use - Commons-Logging and Log4J. |