Object-Oriented Design Heuristics

Description

Upon completion of an object-oriented design, you are faced with a troubling question: "Is it good, bad, or somewhere in between?" Seasoned experts often answer this question by subjecting the design to a subconscious list of guidelines based on their years of experience. Experienced developer Arthur J. Riel has captured this elusive, subconscious list, and in doing so, has provided a set of metrics that help determine the quality of object-oriented models.

Object-Oriented Design Heuristics offers insight into object-oriented design improvement. The more than sixty guidelines presented in this book are language-independent and allow you to rate the integrity of a software design. The heuristics are not written as hard and fast rules; they are meant to serve as warning mechanisms which allow the flexibility of ignoring the heuristic as necessary. This tutorial-based approach, born out of the author's extensive experience developing software, teaching thousands of students, and critiquing designs in a variety of domains, allows you to apply the guidelines in a personalized manner.

The heuristics cover important topics ranging from classes and objects (with emphasis on their relationships including association, uses, containment, and both single and multiple inheritance) to physical object-oriented design. You will gain an understanding of the synergy that exists between design heuristics and the popular concept of design patterns; heuristics can highlight a problem in one facet of a design while patterns can provide the solution.

Programmers of all levels will find value in this book. The newcomer will discover a fast track to understanding the concepts of object-oriented programming. At the same time, experienced programmers seeking to strengthen their object-oriented development efforts will appreciate the insightful analysis. In short, with Object-Oriented Design Heuristics as your guide, you have the tools to become a better software developer.

020163385XB04062001

Downloads

Supplements

Click below for Source Code related to this title:
Source Code

Sample Content

Table of Contents

Preface.


Acknowledgments.


1. The Motivation for Object-Oriented Programming.

Revolutionists, Evolutionists, and the Object-Oriented Paradigm.

Accidental Versus Essential Complexity à la Frederick Brooks.

The Waterfall Model.

The Iterative Model.

Same- Versus Different-Language Prototyping.

Software Reusability.

Corporate Hierarchies of Good Designers.

Introduction to Classes and Object.

Messages and Methods.

Class Coupling and Cohesion.

Dynamic Semantics.

Abstract Classes.

Roles Versus Classes.

Differences in Application Topologies.

When the Action-Oriented Paradigm Goes Right.

The God Class Problem (Behavioral Form).

Another Example of Poor System Intelligence Distribution.

The God Class Problem (Data Form).

The Proliferation of Classes Problem.

The Role of Agent Classes.

Examining the Use of Separate Entity and Controller Classes.

Introduction to Class and Object Relationships.

The Uses Relationship.

Six Different Ways to Implement the Uses Relationship.

Heuristics for the Uses Relationship.

Refining the Amount of Collaboration Between Two Classes.

The Containment Relationship.

Semantic Constraints Between Classes.

Attributes Versus Contained Classes.

More Containment Heuristics.

A Relationship Between Uses and Containment?

Containment by Value Versus Containment by Reference.

Introduction to the Inheritance Relationship.

Overriding Base Class Methods in Derived Classes.

The Use of the Protected Section of a Base Class.

The Width and Depth of Inheritance Hierarchies.

Private, Protected, and Public Inheritance à la C++.

A Real-World Example of Specialization.

Heuristics That Trade Off Design Complexity and Flexibility.

A Real-World Example of Generalization.

The Mechanism of Polymorphism.

A Problem with the Use of Inheritance as a Reusability Mechanism.

An Inheritance Solution to an Interrupt-Driven Architecture.

Inheritance Hierarchies Versus Attributes.

The Confusion of the Need for Inheritance Versus an Object's Dynamic Semantics.

Using Inheritance to Hide the Representation of a Class.

Mistaking Objects for Derived Classes.

Mistaking Object Generalization for the Need to Build Classes at Runtime.

The Attempt to NOP a Base Class Method in Its DerivedClass(es).

The Implementation of Optional Parts of Objects.

A Problem with No Optimal Solution.

Reusing Components Versus Reusing Frameworks.

Introduction to Multiple Inheritance.

The Common Misuse of Multiple Inheritance.

A Valid Use of Multiple Inheritance.

Accidental Complexity In Languages That Do Not Support Multiple Inheritance.

Frameworks That Incorporate Multiple Inheritance.

The Use of Multiple Inheritance in the Design of Mixins.

DAG Multiple Inheritance.

Accidental DAG Multiple Inheritance via Poor Implementation of Optional Containment.

Introduction to Associations.

Associations Implemented Through a Referential Attribute.

Associations Implemented Through a Third-Party Class.

Deciding Between a Containment and an Association Relationship.

Introduction to Class-Specific Versus Object-Specific Data and Behavior.

Using Metaclasses to Capture Class-Specific Data and Behavior.

Using Language-Level Keywords to Implement Class- Versus Object-Specific Data and Behavior.

Metaclasses à la C++.

A Useful Abstract Class That Is Not a Base Class?

The Role of Logical and Physical Object-Oriented Design.

The Construction of Object-Oriented Wrappers.

Persistence in an Object-Oriented System.

Memory Management Issues in an Object-Oriented Application.

Minimal Public Interfaces for Reusable Components.

Implementing Safe Shallow Copies.

Concurrent Object-Oriented Programming.

Implementing Object-Oriented Designs in Nonobject-Oriented Languages.

Heuristics Versus Patterns.

Transitivity Among Design Transformation Patterns.

The Reflexive Property of Design Transformation Patterns.

Other Design Transformation Patterns.

Future Research.

The ATM Problem.

Choosing a Methodology.

A First Attempt at Producing an Object Model for the ATM.

Adding Behavior to Our Object Model.

Explicit Case Analysis Due to Accidental Complexity.

Messaging Objects in Different Address Spaces.

The Processing of the Transaction.

Returning to the Domain of the ATM.

Other Miscellaneous Issues.

Conclusion.

Preface

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 begin to see the problem of prioritizing heuristics.

The design heuristics are defined on a backdrop of real-world examples focusing on the area of design to which each heuristic belongs. The foundation of real-world examples provides an ideal vehicle for explaining the concepts of object-oriented technology to the novice. The end result is that this book is appropriate to the newcomer who would like a fast track to understanding the concepts of object-oriented programming without having to muddle through the proliferation of buzzwords that permeates the field. Yet, at the same time, it appeals to the experienced object-oriented developer who is looking for some good analysis and design heuristics to help in his or her development efforts.

The first chapter looks at the motivation for object-oriented programming, starting with several issues which Frederick Brooks argued in his "No Silver Bullet" paper published in 1987 (see reference 1). My perspective on object-oriented programming is that it is a natural progression or evolution from action-oriented development. As software has become more complex, we are required to remove ourselves one more level away from the machine in order to maintain the same grasp we have on the software development process. Just as structured methodologies removed one level from bottom-up programming, object-oriented technology removes one level from structured methodologies. It is not that bottom-up programming or structured methodologies are wrong and object-oriented programming is right. Bottom-up programming is perfectly valid when there exists only 4K of memory to develop, just as structured methodologies are perfectly valid when only 256K of memory exists. With the advent of increasingly cheaper and more powerful hardware, the complexity of software has skyrocketed. Developers of the early 1980s did not have to consider the complexity of graphical user interfaces and multithreaded applications; simpler menu-driven, single-threaded systems were the norm. In the very near future, no one will buy a software product unless it incorporates multimedia with moving video and voice recognition. The more complex systems require a greater level of abstraction, which the object-oriented paradigm provides. This is no revolution in software development; it is simply an evolution.

Chapter 2 discusses the concepts of class and object, the basic building blocks of object-oriented technology. They are viewed as the encapsulation of data and its related behavior in a bidirectional relationship. The notion of sending messages, defining methods, and inventing protocols are explored through real-world examples. This is the first chapter to list heuristics. Given the small subset of the object paradigm with which to work, these heuristics are fairly simple but no less useful than the more complex heuristics of subsequent chapters.

The third chapter examines the difference between an action-oriented topology and an object-oriented topology. The different topologies of these methodologies contain the kernel of truth behind object-oriented development. Action-oriented development focuses largely on a centralized control mechanism controlling a functionally decomposed set of tasks, while object-oriented development focuses on a decentralized collection of cooperating entities. I am convinced that the notion of a paradigm shift is the change in thinking required to move from a centralized to a decentralized control model. The learning curve of object-oriented development is an equally large unlearning curve for those of us reared in the world of action-oriented development. The real world in which we live is more attuned to the object model than to a centralized control mechanism. The lack of a paradigm shift manifests itself in systems that consist of a central godlike object that sits in the middle of a collection of trivial classes. These systems are built by developers stuck in the mindset of an action-oriented topology. This chapter proposes numerous heuristics for developing optimal application topologies.

Chapters 4 through 7 examine each of the five main object-oriented relationships: uses (Chapter 4); containment (Chapter 4); single inheritance (Chapter 5); multiple inheritance (Chapter 6); and association (Chapter 7) through a series of real-world examples. Most of the heuristics of interest to the object-oriented designer can be found in these chapters. The chapters on inheritance include many examples of the common misuses of the inheritance relationship. This information is vital in reducing the proliferation of classes problem, such as designing too many classes for a given application. The class proliferation problem is a major cause of failure in object-oriented development.

Chapter 8 examines the role of class-specific data and behavior, as opposed to object-specific data and behavior. The invoice class is used as an example of an abstraction that requires class-specific data and behavior. Both the SmallTalk metaclass and the C++ keyword mechanisms are illustrated. In addition, the notion of C++ metaclasses (i.e., templates) is compared and contrasted to the SmallTalk notion of metaclasses.

Chapter 9 examines the role of physical object-oriented design in the development of object-oriented systems. While there is much to say about physical design in general, many issues overlap those discussed in the action-oriented paradigm. Issues such as the granularity of efficient implementation (e.g., look at replacing hardware, then compilers, then mechanisms, and then algorithms, before examining individual language statements to speed up an application) are discussed in great detail in the literature. This text examines physical design issues either that are unique within the object-oriented paradigm or for which the object-oriented paradigm offers unique solutions. These include the notion of software wrappers to hide hostile (i.e. nonobject-oriented) subsystems from an object-oriented problem domain, persistence in time versus persistence in space, object-oriented versus relational database management systems, memory management and garbage collection, reference counting, minimal public interfaces, concurrent object-oriented programming, and implementing object-oriented designs in nonobject-oriented languages.

In 1987 I attended a small workshop at the OOPSLA conference which discussed the past, present, and future of the object-oriented paradigm. During this conference, Kent Beck discussed research Christopher Alexander published in the area of architecture (constructing buildings, not software). Alexander felt that all architecture had an as-yet undescribed quality, which he tried to capture in entities he called patterns. Kent discussed the possibility of looking for patterns, that is, domain-independent solutions to known problems or interesting structures, in object-oriented architectures. Recently, much of the research performed in this area is exploding into the forefront of the object community. This has led me to ask the question, "What is the relationship between heuristics and patterns?" They are obviously related in that they are found in much the same manner. We examine any structure or problem that arises in many different domains. We then try to encapsulate the entity in either a heuristic or a design pattern format. Chapter 10 of this text discusses design patterns and their relationship to design heuristics. I believe the most interesting relationship between patterns and heuristics is that heuristics tell a designer when it is time to apply one of several design patterns. Patterns are too large for the average designer to know, through some intuition, that it is time to apply a pattern. Heuristics, on the other hand, are rarely more than two sentences of text and can be easily applied. The combination of the two can be extremely effective. This chapter also illustrates several interesting properties that design patterns and heuristics share.

The reader should avoid the temptation to criticize the early examples in this text as being too trivial or not within the computer science domain. It is common to hear, early in the lecture, a small percentage of attendees of my courses muttering statements such as, "This information is not useful because I do not program fruit baskets, dogs with tails, or alarm clocks." While it is true that a large part of this book deals with everyday items from the real world, I offer a reasonable explanation. If design heuristics and patterns are truly domain-independent, then why not choose a simple domain in which to teach them? In the design courses I have taught, it is common to hear a design group shouting out, "This is the core-the-apple problem," or "This is the dog-with-an-optional tail" problem. Once a heuristic is understood, it is a simple matter to expand its use to any domain, regardless of the domain's complexity.

I have added Chapter 11 of this book for those who wish a design example with more "meat." Chapter 11 provides an analysis and design problem revolving around the automatic teller machine (ATM) domain. The ATM problem has been widely published in various texts dealing with the object-oriented paradigm. In this case it was chosen because it provides a familiar example that illustrates the use of design heuristics and patterns in a more computer science-like domain. In addition, since it is a distributed system (the ATM and the Bank live in different address spaces), it allows for the illustration of a design technique called "design with proxies." This design technique allows a system architect to ignore the distributed facet of an application at logical design time, deferring these problems until much later in design. This is important since many of the design problems associated with distributed systems can be traced to early convolution due to addressing of distributed processing before a logical design is complete.

On a final note, in all of my courses I have noticed that the class divides into two camps. The first camp likes to live in the realm of abstraction, discussing design for design's sake with little discussion of implementation. The second camp has difficulty understanding the abstractions, but if you show the members of that camp a fragment of code, the picture becomes very clear to them. When this book was sent to reviewers, I asked each reviewer to specify whether this book should illustrate the design examples with C++ implementations. Two reviewers stated that it was obvious that this book requires C++ examples, because the abstract concepts would be difficult to understand without them. Another two reviewers stated that this is a design book and as such has nothing to do with C++, or any programming language for that matter. The other two reviewers were relatively neutral. This leaves me with the obvious dilemma of satisfying both camps. My solution is to provide an appendix to the text with a collection of selected C++ implementations of design examples viewed within that chapter. If you tend to be an abstractionist, you will most likely want to ignore the appendix. If you are the type of person who learns by examining the implementation of abstractions (I live in your camp most of the time), you may want to check the implementation of certain design problems in the appendix. It is my hope that this satisfies those desiring implementations without cluttering the design information with code.

Note: All C++ examples were compiled and tested under Borland C++ 4.5 on a Pentium 100 Mhz IBM PC clone. They should work on your favorite C++ compiler as well.

020163385XP04062001

Updates

Submit Errata