Is IFR Good for Software Engineering ?

Y. B. Karasik,
Thoughts Guiding Systems Corp.,
Ottawa, Canada.
e-mail:karasik@sympatico.ca

Suppose there is a computer graphics editing system which has three editing functions implemented: image zooming, image dragging, and image rotating. Suppose that they work as follows:

Suppose that all three functions are implemented with the help of software objects called listeners. They listen for certain events and if they happen, perform the required actions. The first listener is listening for "RIGHT_BUTTON_PRESSED" event. The second - for "LEFT_BUTTON_PRESSED" and "MOUSE_DRAGGED" events. The third - for "MOUSE_WHEEL_ROTATED" event.

And finally suppose that you need to expand the system by adding a new function of a sub-image selection. It has to work as follows:

In short, you have to implement a new listener that listens for "LEFT_BUTTON_PRESSED" and "SHIFT_KEY_PRESSED" events and do the job if they happen. This is where contradictions come to the fore. There already is a listener that listens for "LEFT_BUTTON_PRESSED" event. It is that which implements image dragging. But this time you do not want the image to be dragged. What needs to be done ?

The simplest resolution of the conflict is to deactivate the listener responsible for dragging if SHIFT key is pressed. Then if "LEFT_BUTTON_PRESSED" event happens, it will be processed by our new listener to start drawing a selection rectangle rather than by the drag listener.

But how to deactivate the drag listener ? IFR suggests that the listener has to deactivate itself by itself. But, "SHIFT_KEY_PRESSED" event has nothing to do with the specification of the drag listener. It has to do with the specification of the new listener. What if the spec changes ? What if SHIFT key is replaced by CNTRL key in the future, for example ? Change the drag listener again despite its own spec has not changed ? These arguments suggest that it is better if the new listener deactivates the drag listener when the corresponding key is pressed rather than the drag listener does it by itself.

Besides, there are other arguments in favour of such a position. The source code of the initial system might be unavailable. This would preclude direct modification of the old listeners. One could try to overcome this obstacle by creating new classes that extend the classes of the old listeners and make the required changes in the extension classes. But then calls to the old listeners have to be everywhere substituted by calls to their extensions, which is also impossible to implement because the source code is unavailable.

In short, there is a plenty of software engineering arguments against following IFR in this particular case. And none in its favour !