1.6 Software Reusability
Another method for controlling the essential complexity is to avoid the development of software all together. Instead of building software, why not buy it? Our MIS developers do not build their relational database; they buy one. If you need a spreadsheet, you will not build your own; you will buy it from Lotus, Microsoft, Borland, or some other vendor. The advantage of buying software is that it is cheaper than building the software, especially when maintenance costs are considered. The major disadvantage is that you get whatever functionality you are given. The software you build yourself meets exactly your specifications, while the software you buy probably does not.
Instead of the term "buying software," many people are now referring to "reusing software." The term "software reuse" has become a major buzzword in the object-oriented community. Why all the excitement with reusing software in the object-oriented world? We have always had software reuse. How many developers have used an if statement in their favorite programming language? How many C programmers have used printf? How many Pascal programmers have used writeln? Why the renewed discussion on software reusability? As it turns out, there is an inverse proportion between the size (or granularity) of the code we reuse and its flexibility. If statements are very small and very flexible, while Lotus 1-2-3 is a much larger level of reuse, but it has a specific purpose. It is thought that the types of constructs found in the object-oriented paradigm find a happy medium between the granularity of the software and its flexibility. Unfortunately, the level of software reuse achieved in object-oriented applications has been disappointing for many developers. There are several reasons for this disappointment, which we will explore in the relevant sections of this text that deal with the specific object-oriented constructs responsible.