Don’t Write for Reuse

Reuse. This was the promise of object-oriented programming. Back in the early 1990’s we were told to move from C to C++ because it promoted reuse. That was wrong.

The way to reuse code is through delegation, by calling a piece of code. Delegation has been around since assembly language so OO languages didn’t introduce it. Being able to keep code and data together in objects does help make code more automatous but most people assumed that the reuse OO promoted was through inheritance.

Inheritance is a powerful feature in OO languages but inheritance has been heavily misused by developers. Inheritance is generally not the best way to promote code reuse. I have a lot more to say about that, which will have to wait for a future blog posts (or perhaps several blog posts.)

My rule of thumb for code reuse is if I have only one client who wants to consume my service then I’ll write the service for that one client. When I get a second client with similar needs then I’ll look for ways to promote reuse. Trying to anticipate what other clients need when I only have one client is inefficient and error-prone. Instead, code for what you need today and if tomorrow you discover you can use some of the pieces you already have then look for reuse. This keeps development focused on tangible results and is, in the long run, more efficient.