InfoWorld Magazine September 14, 1998 (Vol. 20, Issue 37) DOWN TO THE WIRE BY NICHOLAS PETRELEY Mr. Spock and Dr. McCoy give an object-oriented programming tutorial I stumbled across the end of the movie Star Trek: The Undiscovered Country while flipping channels. It was the part where an enemy ship pounds the Starship Enterprise, but the Enterprise can't return fire because the enemy ship is invisible. Spock and Bones do the only logical thing: They retrofit a photon torpedo to contain a scientific research probe, and then program the probe to control the torpedo's navigational system -- all within the few minutes remaining before the Enterprise is blown to smithereens. You may laugh, and well you should. But if you think about it, this is precisely the goal of object-oriented programming (OOP). Many say code reusability is the point of OOP. Bzzt. Wrong. Code does not have to be object-oriented in order for it to be reusable. Programmers have long had at their disposal a number of fascinating non-object-oriented technologies for the reuse of code. There's cut-and-paste and link libraries, to name but two examples. No, the immediate goal of OOP is to make it easier to reuse code. The ultimate goal is to have the ability to take two completely unrelated objects, connect them, and make one control the other in an intelligent and purposeful manner. The Star Trek problem is a perfect example of why it is taking so long for OOP to reach its potential. The torpedo is a simple object. It flies in the direction you point it and goes boom when it hits something. Let's assume it has an internal guidance system with a simple interface for directional input terminals for left, right, up, down, and forward motion. To move the torpedo left and forward, you apply more voltage to the left and forward inputs. Normally, these inputs are controlled by a radar-based guidance system, which we'll remove in order to insert the plasma gas sniffer. The plasma gas sniffer is simple, too. You set it to detect a certain gas, and it tells you how much of that gas is currently present. Its interface is also simple. It outputs a voltage in direct proportion to the amount of gas it detects. You should be able to see the immediate problem. The torpedo is expecting information about which way, and the sniffer only understands which gas and how much. It looks like we'll have to cook up another object, a spinner. The spinner points the sniffer in each of six basic directions (left, right, up, down, forward, backward). The spinner has one input line (connected to the sniffer) and seven output lines, one for each direction and one line to trigger the sniffer. Each time the spinner points the sniffer in a direction, it triggers the sniffer to take a reading and forwards the voltage to the appropriate directional output line. We're done, right? Wrong. What if the output plugs don't fit the input jacks? Worse, what if the sniffer and spinner outputs a different range of voltages than the torpedo expects? The spinner may have an output range of zero volts to 50 volts to each line. The torpedo may have an operating range of zero volts to 3 volts on each directional input. Bummer. I guess we need another object: a scaling voltage converter. So we're finally done now, right? Wrong. The spinner doesn't know anything about the current status of the torpedo, it simply sends directions and doesn't care how quickly or how forcefully the torpedo responds. Without a feedback algorithm to compensate for the response characteristics of the torpedo, the torpedo is likely to stop dead, drift into space, or enter some bizarre flight pattern around the target. Hopefully you are beginning to appreciate that, if we are ever to reap the rewards promised by distributed objects, we need a single standard to emerge for communicating between objects. It is bad enough we have to deal with two major standards, CORBA and Distributed Component Object Model -- there are multiple versions of each. It seems to me that the only way we can ever get life to imitate art -- that is, to make programming as easy as tossing together a custom photon torpedo in Star Trek -- is to get to a point where almost everyone supports a single distributed-object standard. Are you reaping the benefits of object-oriented programming yet? How have you dealt with the problems of making objects work together? Former consultant and programmer, Nicholas Petreley will have a real job soon. Reach him at nicholas_petreley@infoworld.com, and visit his forum at http://www.infoworld.com. Copyright (c) 1998 InfoWorld Media Group Inc. Original Source: http://bit.ly/MXo6rT