5/27/04
<< 72 Squared WeblogIndirect programming
Ed Roman, a brilliant java programmer and author of Mastering Enterprise Java Beans once said that any programming problem can be solved through adding a layer of indirection. I agree ... to a point. The philosophy is this: delegate tasks to objects and allow them to handle the details.
A perfect example is the functionality provided by the SOAP protocol. I have a Java server. It needs to have an ASP server or a PHP server carry out a task. Unfortunately, it does not speak PHP or ASP. What to do? I give them a shared interface to exchange information and a common language - a layer of indirection - that allows them to communicate. The Java server creates a SOAP envelope in XML and passes it via an HTTP POST request to the PHP server. the php server recieves and validates the packet and carries out the request, providing an appropriate response. Problem solved. The Java server does not need to know that the server on the other end is even PHP. It could have just as easily been ASP, or any number of other servers. In fact, the server could have switched platforms and server languages in between the time the last request was initiated. No sweat. This is a perfect example of how a layer of indirection helps distribute tasks transparently and effortlessly, allowing a modular construction of dissimilar peices into a unified whole.
However, building layers of indirection needlessly can cause big problems. Applications with many parts have many more weak points. Ask yourself this: am I taking the most direct route to solving my problem, here? It's the difference between trying to build a limo or building a race car. What do you want your application to do?
I always try to solve the problem in the most direct manner that I can. Needless layers of indirection can slow my app down - make it sluggish, difficult to maintain and difficult to debug. Always keep your end goal in mind. Ask yourself, are you building a limo or a race car?