Object Browsers, Dependency Injection and Adaptation

When I first arrived in New Zealand back in August 2000 I worked for a company that developed software for telcos their Intelligent Network layer. After a few months, I started hearing a lot about something called the Object Browser. It took me some time to pluck up the courage to ask someone what the Object Browser did. It turned out that the Object Browserwas responsible for providing the IN service(s) administrator with a way of configuring their services in the Intelligent Network. I breathed a sigh of relief; the Object Browser was nothing more than an application the ensured that the managed services were configured in a consistent way.

"Is that all", I hear you say.

Yep, that is all there is to it.

Skip forward a few years.

I have recently been hearing, and reading, about the Inversion of Control problem and the way that it is typically solved. This article is wonderfully lucid on the whole subject. It has taken me some time to realise that the phrases inversion of control and dependency injection are just yet another way of talking about configuration.

Ever worked with IEEE definitions and standards? If so, you will know what I mean when I talk about adaptation. Adaptation was the (at the time) ground-breaking idea that enabled the US Federal Aviation Authority to deploy identical pieces of hardware around the US but adapt them for the local environment.

Yes, ... you have guessed correctly, adaptation is configuration.

Adaptation	is	Configuration
Object Browser	is	Configuration
Dependency Injection	is	Configuration

I wonder. Is configuration a bad name? Or is it one that merely locates me on the timeline of software development?

In my darker moments, I wonder how many more times will I experience the renaming of a familiar concpet with an unfamiliar name. I work with computers, that number is bound to be a big one.

References

The Limits of Software: People, Projects and Perspectives, Robert N Britcher.

Inversion of Control Containers and the Dependency Injection pattern, Martin Fowler.