Software reuse
| Line 15: | Line 15: | ||
He goes on to note that the theory has not delivered as much as hoped: | He goes on to note that the theory has not delivered as much as hoped: | ||
:"Unfortunately, the level of software reuse achieved in object-oriented applications has been disappointing for many developers." | :"Unfortunately, the level of software reuse achieved in object-oriented applications has been disappointing for many developers." | ||
| + | |||
| + | == Why reuse doesn't work == | ||
| + | |||
| + | As stated above, reuses is a good idea in principle, but it doesn't always work in practice. Typically what happens is a developer is faced with a problem which appears generic enough that they decide to develop a reusable library in case the same problem appears in a future project. Developing a generic library takes more effort than coding for the specific problem at hand. When dealing with an actual customer, it can be difficult to convince the customer that this is a good idea, since they just want their software to work. The first problem is therefore: The developer usually needs to take some of the initial development effort on their own back. | ||
| + | |||
| + | The second problem is trying to design an interface that can be reused by a project which doesn't exist yet. It is often hard enough to develop interfaces when the requirements for a project are known (if constantly changing), so developing a library to be generic enough for future applications can be very difficult. | ||
| + | |||
| + | The third problem is: no matter how much effort you put into solving problem two, it just never seems to work. A new project comes in with a similar problem to one that you have written a generic library for. But it is just slightly different. It is often things you never envisaged, such as a new project being multi-threaded, and the whole library now needing to be thread safe. Like problem one, it can be hard to convince a customer that this is their problem. Again, they just want their code to work, they don't care about your generic reusable library. The problem here, is that it is often difficult to tell whether developing two independent solutions for each customer would have required less effort than developing the generic reusable library. Ideally the generic solution will eventually pay itself off after being used in several projects. However, this can be a gamble that your library will be useful for future projects. | ||
| + | |||
| + | ... (will add more later) ~[[User:Ryan Mallon|Ryan Mallon]] | ||
| + | |||
| + | |||
== See also == | == See also == | ||
Revision as of 20:04, 7 August 2008
The idea of software reuse has hugely influenced the thinking of the OOD community. Many OOD principles were first developed as an aid to reuse.
Reuse is now unfashionable, because it has proven harder to achieve than everybody expected. But the principles still matter. In fact, some people now argue that designing reusable code is just the same as designing good code.
Martin Fowler 1997 (p. 11) gives a simple overview:
- "If the average professional is asked what the principal benefit of object technology is, the answer is almost always reuse. The vision is that of developers being able to assemble systems from tried and tested off-the-shelf components. Many of these visions have been very slow to appear. In some cases reuse is beginning to show, most notably in GUI development and database interaction. Where they are not appearing is at the business level."
Johnson and Foote 1988 is a very important early paper on OO. Among other things, it provides insight into the reuse mindset.
Granularity of reuse
Arthur Riel 1996, p. 8, makes an interesting observation about reuse. He says reuse is supported by OO (in part) because classes have the right granularity: somewhere between statements/functions and applications:
- "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 [a spreadsheet] 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."
He goes on to note that the theory has not delivered as much as hoped:
- "Unfortunately, the level of software reuse achieved in object-oriented applications has been disappointing for many developers."
Why reuse doesn't work
As stated above, reuses is a good idea in principle, but it doesn't always work in practice. Typically what happens is a developer is faced with a problem which appears generic enough that they decide to develop a reusable library in case the same problem appears in a future project. Developing a generic library takes more effort than coding for the specific problem at hand. When dealing with an actual customer, it can be difficult to convince the customer that this is a good idea, since they just want their software to work. The first problem is therefore: The developer usually needs to take some of the initial development effort on their own back.
The second problem is trying to design an interface that can be reused by a project which doesn't exist yet. It is often hard enough to develop interfaces when the requirements for a project are known (if constantly changing), so developing a library to be generic enough for future applications can be very difficult.
The third problem is: no matter how much effort you put into solving problem two, it just never seems to work. A new project comes in with a similar problem to one that you have written a generic library for. But it is just slightly different. It is often things you never envisaged, such as a new project being multi-threaded, and the whole library now needing to be thread safe. Like problem one, it can be hard to convince a customer that this is their problem. Again, they just want their code to work, they don't care about your generic reusable library. The problem here, is that it is often difficult to tell whether developing two independent solutions for each customer would have required less effort than developing the generic reusable library. Ideally the generic solution will eventually pay itself off after being used in several projects. However, this can be a gamble that your library will be useful for future projects.
... (will add more later) ~Ryan Mallon
