Conclusion

After writing this chapter, I published it on the Object Mentor Web site.^[2] Many people read it and gave their comments. Some folks were disturbed that there was almost no object-oriented design involved. I find this response interesting. Must we have object-oriented design in every application and every program? In this case, the program simply didn't need much of it. The Scorer class was really the only concession to OO, and even that was more simple partitioning than true OOD.

^[2] www.objectmentor.com

Other folks thought that there really should be a Frame class. One person went so far as to create a version of the program that contained a Frame class. It was much larger and more complex than what you see here.

Some folks felt that we weren't fair to UML. After all, we didn't do a complete design before we began. The funny little UML diagram on the back of the napkin (Figure 6-2) was not a complete design; it did not include sequence diagrams. I find this argument rather odd. It doesn't seem likely to me that adding sequence diagrams to Figure 6-2 would have caused us to abandon the Throw and Frame classes. Indeed, I think it would have entrenched us in our view that these classes were necessary.

Am I trying to say that diagrams are inappropriate? Of course not. Well, actually, yes, in a way I am. For this program, the diagrams didn't help at all. Indeed, they were a distraction. If we had followed them, we would have wound up with a program that was much more complex than necessary. You might contend that we would also have wound up with a program that was more maintainable, but I disagree. The program you see here is easy to understand and therefore easy to maintain. There are no mismanaged dependencies within it that make it rigid or fragile.

So, yes, diagrams can be inappropriate at times. When are they inappropriate? When you create them without code to validate them and then intend to follow them. There is nothing wrong with drawing a diagram to explore an idea. However, having produced a diagram, you should not assume that it is the best design for the task. You may find that the best design will evolve as you take tiny little steps, writing tests first.

In support of this conclusion, let me leave you with the words of General Dwight David Eisenhower: "In preparing for battle I have always found that plans are useless, but planning is indispensable."