IoC - Inversion of Control

There are two ways to make bricks.

One, I hire Joe, tell him to get clay, mix the hardening agents, put it in the mold, bake it in the oven, inspect the brick quality, stack the bricks, ..... I am in control of the operation, Joe does as I ask.

Or, I could give Joe a specification of my bricks - and let Joe figure it out. How he does it is of no concern to me - so long as I get the bricks I want, stacked the way I want. Joe asks me for clarifications/suggestions as necessary. He is in control. I chip in when he asks.

Software is built like that too.

You can write software that pulls in external libraries and gets work done. Your code is the active component.

Or, you can write your software as a component that "plugs" into a bigger infrastructure. That infrastructure is the primary controller and calls your component/code as necessary.

This is called Inversion of Control, or IoC.

In Java, most of the time you will find yourself writing components that fit into a framework.

We already saw this in our previous posts - we wrote our servlets to the Java EE specification, and the Tomcat Servlet container called our servlets as necessary.

We also saw this in JSP - we wrote JSP templates and the JSP container transformed them into java classes and eventually HTML as necessary.

We wrote Struts controller and views, and Struts called them as necessary.

We will see more of this IoC pattern repeating as we use more frameworks.