Monday, January 23, 2006

Indirection Is Flexibility

Indirection (n)
1. "indirect procedure or action".
2. "deceitful action that is not straightforward"

Indirection in system design is when instead of explicitly specifying how exactly something is done, we delegate the responsibility to another person/entity. We buy belts that are looser than needed, just in case we get fatter, don't we?

Let's say somebody who's new in town asks us what he should do to start a bank account. We could -
a) tell him to go to the bank and meet the manager there.
b) give him the exact list of required documents, the order in which to submit them and to whom.

Take into account the always-changing laws and the idosyncrasies of different banks, and the advantages of the first approach are self-evident! That's indirection for you. We would of course give him the address of the bank and possibly also the title of the official (manager, if he is a life-newbie as well).

Indirection helps us surmount change. In programming, we achieve indirection through the use of pointers and references instead of actual objects. Indirection is closely related to the concept of abstraction.

OO perspective: Instead of specifying the exact type of the implementor, we just mention that it will be of a certain type,say, Base . This is the foundation on which most design patterns are constructed. We can later on replace this reference with a more specialized object (derived from Base), if needed, to provide extra/changed functionality.

Other examples:
The use of virtual machines like .NET's CLR or Java's JVM instead of the actual processor gives us portability as a useful side-effect.
The use of pointers in C/C++ gives us space-efficiency.

There ain't no such thing as a free lunch. Indirection gives us flexibility at the expense of performance. No matter how trivial the cost is, there is a price to be paid. You can't have your cake and eat it too!

No comments: