Chapter 10: Organizing the Problem for Reuse: Reuse of Utility Classes

---

10.1 Introduction

The first nine chapters of the text have been concerned with creating the framework for the solution to a problem that is to be implemented on a computer using components. Once the framework of a problem solution has been specified, we still must decide how to organize the pieces that will be used within that framework. This involves figuring out how to organize the data and methods in the program and is called problem decomposition. Decomposition can involve either not saving a state between invocations of a method (procedural functions) or saving a state between invocations of a method (using objects).

Objects can be organized according to composition or classification. Composition and classification are techniques that define the relationships between the classes used in the program, allowing methods and variables for one class to be used as part of the definition of other classes. The ability to use part of the definition of one object in another object is called reuse and was one of the original reasons why object-oriented programming (OOP) was developed.

When designing the objects in a program, classes are defined and used in two ways. In the first, classes in the program are designed around entities in the problem specification after properties intrinsic to a specific problem have been identified. This allows reuse but is really part of the design of the system and as such is treated as object-oriented design (OOD) (covered in Chapter 11). In the second, classes are based on functionality that is extrinsic to the problem and thus can be used in many problems; the classes can be created to be used in a number of systems, or existing classes or methods can be identified that have the desired functionality. These methods and objects provide a service to be utilized by the current program; therefore, this type of object design is called utility reuse. Examples of utility classes are Vector or StringTokenizer objects, and examples of utility methods are Integer.parseInt or Math.random.

This chapter specifically covers utility reuse. Because utility reuse deals with methods, classes, algorithms, and components that are not specific to a problem, but occur across a wide variety of problems, this chapter is not concerned with designing objects in the problem; rather, it focuses on identifying and reusing functionality that occurs across a wide range of applications and making that functionality generally available. This chapter explains the four major types of utility reuse: reuse by copy, method reuse, and the two types of object reuse, composition and classification. The two types of object reuse are examined in detail using the move method (introduced in the gas station simulation in Chapter 8) to illustrate each type of reuse and how code can be refactored to take advantage of the reuse. The chapter then contrasts the two types of object reuse and uses the criteria of cohesion and coupling to show why composition is nearly always superior to classification designing for reuse of utility objects.

The chapter concludes by examining two components, the animator component from Chapter 6 and the java.util.Stack class, to show why a design using composition is superior. Once again, this discussion emphasizes why compositional design is nearly always superior when implementing reuse of what is essentially a utility object.

---