Good design skills implies better refactoring

published: Mon, 17-Apr-2006   |   updated: Mon, 17-Apr-2006

(This article is also published on ctodx.)

I was pondering this over the weekend. Is refactoring always good?

With the support for refactoring in C# in Visual Studio 2005 and also Refactor! Pro from those awfully nice people at Developer Express, you'd think life is good. We can refactor all we like, all the time.

The problem is, I think, that doing refactoring for refactoring's sake is just not a great way of spending your time. Going back to Martin Fowler for a moment, he says that "Refactoring is the process of changing a software system in such a way that is does not alter the external behavior of the code yet improves its internal structure," and "in essence when you refactor you are improving the design of the code after it has been written." [Page xvi of "Refactoring"]. In other words, in refactoring some code you are not only trying to make sure that you don't change the external effect of the code (where are your unit tests, then?), but you are trying to enhance (improve? clean up? simplify?) the design (or structure) of the code in doing so.

You can't just apply refactorings willy-nilly. You have to have some idea, a hazy design in the back of your mind, that's leading you towards a better structure, cleaner code.

So your guidance in your refactoring exercises should be your knowledge of good design. You should know the Design Patterns, especially important ones like Abstract Factory and Strategy. You should understand the difference between implementation inheritance and interface inheritance, and know when to apply either one and what the benefits and drawbacks of both are. You should have some idea of object-oriented design principles like the Single-Responsibility Principle and Tell, Don't Ask.

In other words, before you can get the maximum benefit from such great tools as Visual Studio and Refactor!, you have some learning to do first. You have to be a good object-oriented programmer.