Reuse is not only code reuse

Reuse is often assumed to mean code reuse, but there are many other kinds of reuse. You can also reuse ideas, and even reuse the process of applying ideas.

Why reuse?

We want to reuse prior work or knowledge for several reasons:

  1. It is easier to reuse than to redo the effort that would lead to the same result.
  2. We want the best result, and the simplest way to ensure that is to reuse the solution considered to be the best in its field.
  3. We want to keep something in only one place, following the DRY principle.

Ready-made reuse

Circuit-bending is about reusing old toys to create weird musical instruments

Reuse is often assumed to mean code reuse, or at least reuse of something already written:

  • API, library or framework: code is packaged to be easy to (re)-use, and perhaps easy to customize.
  • Code snippet: example code is provided for copy-and-paste inclusion into the code under construction. Code snippets can also be tweaked.
  • Declaration files templates: many frameworks or build tools supply declarations files that can be either reused and tweaked, or imported and modified through some inheritance mechanism, such as Ant build files.
  • Aspects: Aspects isolate how to address cross-cutting concerns, and can be reused as coded aspects in AspectJ for example. However applying the aspect must be done by the developer.

Ready-made reuse is the simpler kind of reuse: take it and use it, as it is. It is a no-brainer. The drawback is that this cookie-cutter approach lacks flexibility to adapt to each particular case, unless you leave the road and start to customize at your own risk.

Ready-made API’s often try to workaround this lack of flexibility through extensive options of configuration.

Reuse of ideas

However there is another kind of reuse, in the form of ideas to apply each time into the project under construction. This knowledge prepared and canned in advance can take various forms:

  • Algorithms: an algorithm is often reused without code reuse, by applying the algorithm on the particular data structure at hand.
  • Patterns: patterns are an obvious mean of reuse, and most of the time they must be applied into the code in progress, rather than imported through an API or through libraries.
  • Specifications: knowing the “what to do” can also be reused, we can reuse specifications. This is especially true when re-building from scratch an existing legacy application: the legacy application can be reused as a working piece of specification, rather than reusing its actual code (which we usually do not want to reuse).
  • Issues History: the history of issues already encountered and stored in a bug tracker has value for reuse too, because it can be considered a check list of possible traps when refactoring or when starting another similar project.

When reusing ideas, you have to think deeper, which is good for your brain. But because you have to take decisions to apply each idea you reuse, it takes more time and more effort, and the end result will also depend more closely on your design and coding skills.

But on the other hand, you get the maximal flexibility, or how to build the solution that perfectly matches the needs of each particular situation. This is invaluable, and this is why ready-made reuse is not always desirable.

Automated reuse of ideas

When ready-made reuse is not desirable, it may remain desirable to automate the process of applying codified ideas to a project under construction. The twist here is to reuse the process of applying ideas, rather than the ideas themselves.

Several examples of this approach already exist:

  • Code generation, method and field injection: generation and injection of code is a process to enable reuse of prior knowledge and effort, concentrated into a generator. For example in the tool JiBX, the knowledge of how to serialize beans into XML is canned into a bytecode generator.
  • Macros and C++ templates: just like code generation, macros and templates are processes that apply codified ideas to program elements in an automated fashion. Note that this is not the case with Java or .Net generics, which are just plain (generic, really) code reuse.
  • Middleware magic: interception, dynamic proxies and other decorators created behind the scene by most JEE application servers are a form of reusing ideas by applying them to each specific entity or service.
  • Compiler or VM optimization: automatic compiler optimizations have removed the need to manually optimize code for most cases, thanks to automatic application of many optimization techniques.

If we want to automate further the application of ideas onto code, we need better ways to guide the tools. For a tool to apply an idea onto existing code, you need to describe what you want to the tool. If the required amount of user input is excessive or if it is impossible to tell a tool your intent, you’d better of doing the work manually. This is the limiting factor toward more powerful tools.

More explicit, more reuse

By making intents and concepts more explicit in the code, tools can increasingly automate tasks that otherwise would remain manual tasks:

  • Maven POM: Maven makes project information explicit in its project object model (POM), and as a result each plugin can configure itself. A plugin that needs to know where to find the source code files can access the information by itself, and this can be seen as a reuse of a predefined configuration. In contrast, with Ant you must configure the information repeatedly for each task.

Imagine now a cross-cutting concern “Auditability” which requires to “record every action that changes the state of an entity”.

In other words we need to record every action that is not safe, as defined in REST. If we can explicitly declare on each operation and service whether it is safe or not (e.g. using annotations), then a tool can automatically weave a predefined Aspect for Auditability, without any specific configuration.

This example illustrates how we can reuse both the aspect (ready-made reuse) and the configuration of its pointcuts (i.e. reuse of the process of applying the aspect), thanks to a new concept (Safe) made explicit in the code.

I believe there are still many other forms of knowledge that could be reused automatically, and this looks like an exciting area of investigation.


Software development, Domain-Driven Design, patterns and agile principles enthusiast