10.3 Types of Reuse

 < Day Day Up > 



10.3 Types of Reuse

When implementing a computer program, functional or data commonality exists in the program and across many programs. It is generally accepted that this commonality should be found, factored out, implemented once, and then reused throughout the program. Entire development methodologies, such as extreme programming, invest heavily in the idea that large improvements in a program are achievable if common functions and classes are refactored, implemented, and stored once and then reused throughout one or more programs.

Reuse can occur in a program in two ways. The first type of reuse occurs when an algorithm, object, or component is built to operate on a generic data type. This type of reuse, which we call generic reuse, builds an algorithm or component around an interface (generic type) and then reuses the algorithm or component with types defined at runtime. This type of reuse is used in the GUI components in the Java AWT, the animator from Chapter 7, and the SortedPrintTable from Chapter 5. It can also be used in algorithms, such as a generic sort algorithm, and is often used in components. This has already been covered in detail and is not examined further in this chapter. The second type of reuse occurs when existing functionality is used as building blocks to create other procedures or objects. For example, a common method, such as Integer.parseInt, might be used to convert input data from a string to an int; a vector might be used to store objects as part of the Java Event Model; or a problem-specific data type, such as a car, could be defined and extended by a number of different car type objects. In each of these cases, some base functionality has been implemented, and that base functionality is extended to create larger methods or objects.

Decomposing objects when implementing reuse of functionality is done for two reasons. The first is to look at objects and methods that are specific to the current problem, to factor out the commonality between these objects and methods, and finally to implement these objects in ways that will allow them to be reused to solve the current problem (this is what we refer to as object-oriented design and is covered in Chapter 11). The second reason is to be able to look at the objects and methods that are not part of the current problem definition but which are needed to actually implement the program. For example, a problem may have to store a set of employees. While the set of employees is problem specific, the mechanism to store a collection is much more common than just its use in the current program. The storage can therefore be accomplished using an object, such as a Vector object, that is not problem specific. The Vector object is not part of the current problem but is simply a helper object necessary to implement the program. These helper objects and methods provide utilities to handle commonly recurring tasks; hence, these objects and methods are referred to as utility objects, and this type of reuse is called utility reuse. Utility reuse is the subject of the remainder of the chapter.

Utility reuse falls into two main categories. The first is when a series of statements, or a method with no state data, is reused in a program. In this case, no variables are used to store values between invocations of the method. The method does calculations on the current input data, producing results that are only dependent on the input parameters. Examples are converting strings to numbers (e.g., Integer.parseInt) or creating random numbers (e.g., Math.random). In these methods, the only thing being reused is the procedure, or a series of statements that does the actual calculation; hence, this type of reuse is referred to as procedural reuse, which can be achieved in two ways. The first is to find a section of code in a program that does basically what is needed, copy that code to a new place in the program, and modify the code to fit the current problem, a process known as reuse by copy. The second approach to procedural reuse is to find a section of code in a program that does basically what is needed and use it to create a method; parameters can then be added to the method to make it work in a number of different situations. This type of reuse is called method reuse. Because these methods do not require data, or state, to be maintained between their invocations, they are often referred to as stateless methods and are implemented as static methods in Java.

Utility reuse can also occur when a state needs to be maintained between invocations of a method. For example, in the Vector class, when an add method is called the object sent as a parameter must be stored so that it can be accessed in subsequent calls. The objects that are stored represent a state for the Vector object, and the methods required to encapsulate, store, and retrieve objects in the vector must save and access this state between invocations. So, a program reusing methods that must maintain a state has to create objects to keep that state, thus we call this type of reuse object reuse. To achieve object reuse in a program, objects must be extended in some way, either by classification or composition. These two methodologies are nearly interchangeable, but each has its own advantages and disadvantages. This chapter examines these advantages and disadvantages and draws conclusions about criteria for choosing one method over the other, particularly for utility reuse. Chapter 11 looks at this question in more detail as it relates to OOD.

The remainder of this chapter examines the reuse utility, particularly regarding the question of using composition or classification for reusing objects. The move method introduced in the gas station simulation in Chapter 8 is used to explain the concepts, but, to simplify the example, a program that simply moves a ball in a thread will be used. The move method is implemented procedurally first by copy and then as a method. The shortcomings of procedural reuse for this situation are explained, and objects are created to allow the move method to be used in more than one object. Both a composition and two classification solutions are presented, and the relative merits and problems of them are discussed.



 < Day Day Up > 



Creating Components. Object Oriented, Concurrent, and Distributed Computing in Java
The .NET Developers Guide to Directory Services Programming
ISBN: 849314992
EAN: 2147483647
Year: 2003
Pages: 162

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net