Advertisement

API design and refactoring

Bill Venners: How does focusing on API design serve you well in the refactoring process? I believe I heard you say that developers won't have to do as much refactoring.

Josh Bloch: That's part of it. In addition, refactoring is often ex post facto API design. You look at the program and say: I have almost the same code here, here, and here. I can break this out into a module. Then you carefully design that module's API. So, whether you do it at refactoring time or up front, it's the same process.

In truth, you always do a bit of both. Programming is an iterative process. You try to do the best you can up front, but you don't really know whether you have the API right until you use it. Nobody gets it right the first time, even if they have years of experience.

Doug Lea [author of Concurrent Programming in Java] and I chat about this issue from time to time. We write stuff together, and, when we try to use it, things don't always work. In retrospect, we make obvious API design mistakes. Does this mean Doug and I are dumb? Not really. It's just impossible to predict exactly what the demand will be on an API until you have tried it. That's why whenever you write an interface or an abstract class, it's critical to do as many concrete implementations as possible before committing to the API. It's difficult or impossible to change it after the fact, so you better make sure it's good beforehand.