The software engineering literature identifies many kinds of reuse [Leach, 1997], but for our purposes we will focus on three kinds:
These reuse practices are summarized in the following table:
The provider | The product | The receiver (reuser) | |
Application Reuse | you, the product vendor | application (mathlet) | teachers |
Designing for Reuse | you, the producer | component or source code | developers |
Code reuse | developers | component or source code | you, the consumer |
Given all those benefits, why doesn't everyone engage in reuse? First, designing for reuse costs more than not designing for reuse, because it takes more effort to design and develop code that works outside of a specific application and to create associated documentation and tests. However, much of this effort should be considered good programming style, and the effort will pay off when you reuse your own code. Second, the code may be a trivial implementation or a toy example in which designing for reuse would consume most of the coding effort.
There are also some issues when reusing code. First, the code you may want to reuse may have a licensing policy you disagree with or may be prohibitively expensive. Second, it takes effort to find suitable code to reuse, select when there is more than one candidate, and understand the code. Third, there's the educational value of coding it yourself. You may not want to reuse code if you're teaching yourself to program. However, most professional programmers today reuse code whenever they can.