Prefactoring

Getting it right first time

Book review The title of this book should have been "Pre-refactoring", and for a suitable subtitle, "Getting It Right First Time" would have been a bit more informative than "Extreme Abstraction, Extreme Separation, Extreme Readability", which is a bit extreme on the extremes.

Refactoring, for those unfamiliar with the phrase, was coined by Martin Fowler in his influential book of the same name. It describes the process of improving the structure of the code without necessarily changing the functionality. Typically, this means rewriting code, reorganising classes, and redesigning software without breaking any applications that use the code. Think of it as an under the covers exercise that is invisible to consumers of an API or class library.

Prefactoring was successful in both articulating a common practice and also identifying and abstracting a range of refactorings that are generic and useful in many different situations. These days users of heavy-weight IDEs, such as Eclipse or Visual Studio .NET, have refactoring support a mouse click away.

Ken Pugh has taken on board the lessons learned from refactoring and worked them back to the beginning of the design process. Refactoring very often is about decoupling code so that dependencies between classes are minimised – this makes code more flexible, easier to maintain, and far less brittle. Hence the "Extreme Separation".

Another common problem is dependence on primitives (such as int, boolean etc), rather than on abstract data types which have semantics that reflect their contents. By using classes rather than primitives it is easier to add validation rules, enforce constraints, add additional methods and so on. This is the "Extreme Abstraction" from the subtitle. This also links in to "Extreme Readability". Using meaningful levels of abstraction is part of making code that is easy to read and understand. It's an acceptance that code needs to be developed and maintained, and should therefore be designed with that in mind.

Pugh makes his case both through argument and through the use of an extended example (coded in Java) that runs throughout the book. A web application for the rental of CDs provides ample scope for illustrating the value of the prefactoring approach. Developed using a fairly agile process, the sample project expands through a series of prototypes and requirement changes which show the pay-offs of using all those extremes.

Having a worked example gives the book a narrative that drives it along, and there are plenty of side-bars, rules, practices and other information to make it more than just a piece of source code fiction. Additionally, the final two chapters each provide another worked example, a print server and some anti-spam software respectively. For those that learn most from looking at code, these final chapters recapitulate the contents of the rest of the book.

Prefactoring

Verdict: This isn't a particularly long book, and it would have been shorter without the narrative, but it's an easy read. Its core lessons, which are to do with improving the design of software, are certainly worth learning.