OBJECT-ORIENTED DESIGN HEURISTICS

020163385XB04062001

In the process of teaching object-oriented analysis, design, and implementation to several thousand students, it became clear to me that the industry was in serious need of guidelines to help developers make proper decisions. Since 1987 I have scoured the literature in search of productivity and complexity metrics that can be applied at different levels of development to improve an object-oriented application. I added my own "homemade" guidelines to those found in the literature and came up with approximately 60 guidelines, several of which are tongue-in-cheek yet no less important than any others. I briefly considered calling them the "Sixty Golden Rules of OOA/D," but I recalled Dykstra's legendary "Goto Considered Harmful" paper, which branded users of goto statements heretics who should be burned at the stake in the company courtyard. That paper was important in that it provided an industry rule that stopped the users of goto statements who were destroying, wittingly or unwittingly, the maintainability of their systems. Unfortunately, the side effect of such a rule was the breeding of a group of pathological authors who, for the past 25 years, have published articles stating that the judicious use of a goto statement in some picky little piece of an application is more readable than a corresponding piece of structured code. Of course, these papers were followed up by a half-dozen rebuttal papers, which were themselves rebutted ad nauseam.In order to prevent the same pathology from occurring, I refer to these 60 guidelines as "heuristics," or rules of thumb. They are not hard and fast rules that must be followed under penalty of heresy. Instead, they should be thought of as a series of warning bells that will ring when violated. The warning should be examined, and if warranted, a change should be enacted to remove the violation of the heuristic. It is perfectly valid to state that the heuristic does not apply in a given example for one reason or another. In fact, in many cases, two heuristics will be at odds with one another in a particular area of an object-oriented design. The developer is required to decide which heuristic plays the more important role.This book does not invent yet another object-oriented analysis or design methodology, though the idea of creating "Riel's OOA/D Methodology" was tempting. The industry already has enough methodologies offering similar or overlapping advice, using a completely different vocabulary for common concepts. The typical problem of the object-oriented developer - which has not been seriously addressed - occurs once a design has been completed, regardless of the methodology used. The developer's main question is, "Now that I have my design, is it good, bad, or somewhere in between?" In asking an object-oriented guru, the developer is often told that a design is good when "it feels right." While this is of little use to the developer, there is a kernel of truth to such an answer. The guru runs through a subconscious list of heuristics, built up through his or her design experience, over the design. If the heuristics pass, then the design feels right, and if they do not pass, then the design does not feel right.This book attempts to capture that subconscious list of heuristics in a concrete list backed up by real-world examples. The reader will become immediately aware that some heuristics are much stronger than others. The strength of a heuristic comes from the ramifications of violating it. The reader does not get a prioritized ordering of the heuristics. It is my feeling that in many cases the sense of priority is defined by a combination of the application domain and the user's needs and cannot be quantified here. For example, a common area of design where two heuristics might request opposite directions are those that trade complexity with flexibility. Ask yourself which attribute a software designer desires most, increased flexibility or decreased complexity, and you be