Designing Reusable Classes

Ralph E. Johnson & Brian Foote

Software reuse does not happen by accident, even with object-oriented programming languages. System designers must plan to reuse old components and must look for new reusable components.

Evolutionary lifecycles are the rule rather than the exception. Software maintenance can be categorized as corrective, adaptive, and perfective

Classes usually start out being application dependent. It is always worthwhile to examine a nearly-complete project to see if new abstract classes and frameworks can be discovered. They can probably be reused in later projects, and their presence in the current project will make later enhancements much easier. Thus, creating abstract classes and frameworks is both a way of scavenging components for later reuse and a way of cleaning up a design. The final class hierarchy is a description of how the system ought to have been designed, though it may bear little relation to the original design.

One sign that a good abstraction has been found is that code size decreases, indicating that code is being reused. Many Smalltalk projects have periods in which the size of the code increases at a steady rate, followed by periods in which little change occurs to the code, followed by a sharp decrease in the size of the code. Code size increases as the programmers add new classes and new methods to old classes. Eventually the programmers realize that they need to rearrange the class hierarchy. They spend a bit of time in debate and experimentation and then make the necessary changes, usually creating a new abstract class or two. Since Smalltalk programs tend to be compact, it is feasible to rewrite a system many times during its development. The result is much easier to understand and maintain than typical nonobject-oriented systems.

Finding new abstractions is difficult. In general, it seems that an abstraction is usually discovered by generalizing from a number of concrete examples. 

Rules for Finding Standard Protocols

Rule 1: Recursion introduction

Rule 2: Eliminate case analysis

Rule 3: Reduce the number of arguments

Rule 4: Reduce the size of methods

Rules for Finding Abstract Classes

Rule 5: Class hierarchies should be deep and narrow

Rule 6: The top of the class hierarchy should be abstract

Rule 7: Minimize accesses to variables

Rule 8: Subclasses should be specializations

Rules for Finding Frameworks

Rule 9: Split large classes

Rule 10: Factor implementation differences into subcomponents

Rule 11: Separate methods that do not communicate

Rule 12: Send messages to components instead of to self

Rule 13: Reduce implicit parameter passing