This Blog


Favorite Posts


Good design skills => better refactoring

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.

Published Apr 17 2006, 07:12 PM by
Bookmark and Share


Scott Bussinger

Another negative to "willy-nilly" refactoring is that it can make it hard to look through a file's version control history and really see what the evolution of that file has been. If you see 13 revisions and 7 of them are just refactorings for the sake of marginal improvements it a lot harder to pick out the important points.
April 18, 2006 12:08 AM


So, when is refactoring bad? Can it be defined? The core of any good design, not just programming, is consistency.(IMO) I have learned many years ago that it is almost always much easier to correct a problem that was consistently wrong, rather than something, as you stated, is "willy nilly".

Therefore, refactoring can make a problem worse, rather than better, if it destroys consistency. Once refactoring is started, it must be completed throughout... consistently.

April 25, 2006 2:17 AM

About Julian Bucknall (DevExpress)

Julian is the Chief Technology Officer at Developer Express. You can reach him directly at julianb@devexpress.com. You can also follow him on Twitter with the ID JMBucknall.

Chat is one of the many ways you can contact members of the DevExpress Team.
We are available Monday-Friday between 7:30am and 4:30pm Pacific Time.

If you need additional product information, write to us at info@devexpress.com or call us at +1 (818) 844-3383


DevExpress engineers feature-complete Presentation Controls, IDE Productivity Tools, Business Application Frameworks, and Reporting Systems for Visual Studio, Delphi, HTML5 or iOS & Android development. Whether using WPF, ASP.NET, WinForms, HTML5 or Windows 10, DevExpress tools help you build and deliver your best in the shortest time possible.

Copyright © 1998-2018 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners