Different Forms of Software Reuse

Software reuse has always been one of the goals of software development since the beginning. If there is something already there and working perfectly fine, why do we want to reinvent the wheel? People tried many different techniques in the past. Here are what I think the different forms of software reuse.

Let's first visit reuse within a single application or project.

Copy and Paste. This is the most primitive form of reuse. Some may not agree that it is a form a reuse. Some even think it is anti-reuse. You see a code snippet that is exactly what your are looking for. Why do I have to reinvent the wheel again? You copy the code and paste it to the new place. Everybody knows that it is bad, but some do that still. The main problem is the maintenance. If we want to change the code snippet, we have to change it in many places. Once a code snippet is copied, the original and copied version evolve independently.

Refactoring. You massage the code using various techniques such as Object-Oriented design (OOD), Aspect Oriented Programming (AOP), or just simply create utility packages. The result is that the code and logic stays in one place. Application becomes easier to understand and maintain. This is great. However some code and logic can be shared among projects.

Now that's look at reuse across applications.

Source-code Reuse. You obtain the source code from other project or some common code repository, and incorporate it into your own project. It may sound ok at first, but it is the equivalent of "Copy and Paste", only it happens at a different level. You may even modify the code to meet your own need. Such modification is hard to track and maintain.

Binary-code Reuse. You obtain and use the reusable asset in the form of binary library. It is better than Souce-code Reuse. At least you know there is no modification to the asset. In many cases, this form of reuse is the best option we have. However it still have the maintenance issue. For example, a new release of an asset fixes some defects. In order to get the fixes, each individual project must download the new release and incorporate it into the project.

Runtime Reuse. What if we package the reusable logic and stand it up as a service? So instead of embedding reusable code into each individual applications, let applications "use" the shared service at runtime. Yes, we are talking about Service-Oriented Architecture here. Of cause, we can't turn everything into services. SOA has it own issues such as service versioning and governance to worry about.