© Jennifer M. Kohnke
In the mid-1990s I was deeply involved with the discussions that coursed through the comp.object newsgroup. Those of us who posted messages on that newsgroup argued furiously about various strategies of analysis and design. At one point, we decided that a concrete example would help us evaluate one another's positions. So we chose a very simple design problem and proceeded to present our favorite solutions. The design problem was extraordinarily simple. We determined to show how we would design the software inside a simple table lamp. The table lamp has a switch and a light. You could ask the switch whether it was on or off, and you could tell the light to turn on or off: nice, simple problem. The debate raged for months. Some people used a simple approach of only a switch and a light object. Others thought there ought to be a lamp object that contained the switch and the light. Still others thought that electricity should be an object. One person suggested a power cord object. Despite the absurdity of most of those arguments, the design model is interesting to explore. Consider Figure 33-1. We can certainly make this design work. The Switch object can poll the state of the actual switch and can send appropriate turnOn and turnOff messages to the Light object. Figure 33-1. Simple table lamp
What don't we like about this design? Two of our design principles are being violated by this design: the Dependency-Inversion Principle (DIP) and the Open/Closed Principle. (OCP) The violation of DIP is easy to see; the dependency from Switch to Light is a dependency on a concrete class. DIP tells us to prefer dependencies on abstract classes. The violation of OCP is a little less direct but is more to the point. We don't like this design, because it forces us to drag a Light along everywhere we need a Switch. Switch cannot be easily extended to control objects other than Light. |