“The control is inverted – it calls me rather me calling the framework. This phenomenon is Inversion of Control.”

“Inversion of Control is a key part of what makes a framework different to a library. A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client.” – 

A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework’s code then calls your code at these points.” – 

It’s fascinating to me how much work one can get done without purely understanding the academics behind the various APIs we use daily. Even more so is that some languages essentially require you to know these concepts right off the bat, where others it’s completely optional. Java is a clear example of the former, but it’s not until you start working with modern frameworks does this concept come into play.

Interestingly Martin doesn’t spend much time on why this design pattern is so important. Merely that it exists and is useful to make frameworks. I’ve never really thought of it in those terms. For me, it’s an excellent way to set up a demarkation boundary between development teams. Furthermore, using this pattern, you can arrange your code such that maintenance is easier. We used this pattern for great effect at PBC/PlaySpan but I guarantee you nobody had a clue what was really going on.

Whenever the new hires came on, the organizational structure of the code was one of the first things taught, along with pointing out the “DO NOT GO PAST THIS POINT” lines. This approach allowed us to have new programmers immediately effective, without risk to the rest of the codebase.

Note to self: time to do a J2EE review…