Inversion of Control

I've been in the Cocoa/CocoaTouch world now full time now for more than two years. But I still remember bits and pieces of my former life in the Java IT world. One of the hot topics there (or it was hot 2 years ago) was Spring.

Spring was such a big thing because it relieved Java programmers from the tedious complex nature of J2EE programming and made it fun and simple again to write apps. The main idea behind Spring was coined 'Inversion of Control'. The term came from the fact that the controller class you were writing did not need to know where its JDBC (database stuff) connection came from, instead it just relied on the connection being set by someone else. In other words the controller gave up control of knowing everything about its dependent objects at all times for a much simpler programming model.

It struck me during the last studio that Daniel and I were teaching that Interface Builder and the loading mechanism for nib files is a lot like the Spring module loading stuff. Sure you give up control and knowing everything all the time, but what you get is priceless.

One example is the files owner. I don't remember the exact term used in Spring but you can declare a bean in a spring config file that says 'I represent an object that will be supplied at load time' and then proceed to add configuration for that bean despite the fact that the object is created elsewhere. Before this file is loaded none of the configuration represented there has been performed, despite the object being created. When you need the configuration, you load the spring file and bada-boom, bada-bing you have your configuration.

In IB you create a nib file and set the file's owner to some class of your making. You connect the view, wire up some actions to buttons or other controls etc. But none of that configuration is available until the nib file is loaded. Consider a nib file whose file's owner is one of your view controllers, you create the instance of the VC in a parent nib file. When that nib is loaded the VC is created, but it does not have a view or the target/action connections specified in the child nib file. However when it's asked for it's view and the nib file is loaded all those connections are made.

The much simplified bunch of code that you get is one thing, but even better is that you get a simplified programming model. True that much of the simplified programming model comes from the way that Cocoa Touch works. But, most of the design patterns used in Cocoa Touch are influenced by IB (and vice-versa).

My hope is that if you are coming from Java and you are familiar with Spring that this write-up will help you to get a little further along in your understanding of IB and how it works. Just like spring folks would never dream of writing an IT app in the old style (J2EE 2.0 old style) because of its complexity, I would never dream of writing an iPhone or Mac app without using IB, why would I poke myself in the forehead with a sharp stick :)

Give up your need for control and be happy!