Refactoring to Patterns

Missing ReSharper Feature - Refactor to Design Pattern

Dave Hayden — Fri, 21 Sep 2007 13:55:00 GMT

Missing ReSharper Feature - Refactor to Design Pattern

Last night I needed to refactor some conditional logic to a particular strategy. Already having gone through roughly the same set of refactoring steps to do this in another section of the application, I thought to myself - “Why doesn't ReSharper have an option to refactor code to a particular design pattern?”

In particular, I think refactoring to the strategy pattern is a fairly easy refactoring that could be done by ReSharper. One of my favorite books, Refactoring to Patterns by Joshua Kerievsky, is a really nice catalog of refactorings explaining step-by-step how you could achieve various refactorings to patterns.

Obviously it is important to understand the refactoring steps without a tool. You don't want to get yourself into tool dependency. But, certainly the option of having ReSharper apply several refactorings for you to a particular design pattern is a very productive thing. You always have the option of applying the steps yourself in case you feel yourself getting a little rusty :)

Refactoring Webcast - Refactoring For Your Code Base - Excellent Introduction to Refactoring

Dave Hayden — Sat, 28 May 2005 11:34:00 GMT

Last night I watched an MSDN Webcast, called Refactoring For Your Code Base (Level 300). Brian Button was the presenter, and let me say that he did an excellent job presenting the material. The presentation was a very nice balance of slides and refactorings demonstrated in Visual Studio. The demonstrations were very easy to follow and the webcast is a fantastic introduction to refactoring.

His first demonstration showed the “Rename” and “Extract Method” refactorings. Briefly, he demonstrated how a tool like JetBrains ReSharper could help you with such refactorings. However, Brian wasn't pushing or recommending any tools, he just wanted to introduce the fact that there are tools available and that Visual Studio 2005 would also have some refactoring capabilities as well. Nicely done, Brian, as I would have recommended that all C# developers run, not walk, and buy ReSharper. You're a better man!

His other demonstrations showed a number of other refactorings, like “Extract Superclass”, “Pull Up Constructor Body”, “Pull Up Field”, etc. Again, it was really easy to follow the refactorings and they were all done by hand to show the refactoring process and not demonstrate a tool.

As you would expect, refactoring was done in very small steps and Brian had a set of unit tests pre-written to demonstrate the importance of unit tests when refactoring. Brian didn't dive into the tests and how to create them, which in my opinion was a smart move. He just reinforced from time-to-time the value of the unit tests as a safety net when doing the refactorings. He also ran the unit tests after every small change / refactoring which supported his words, yet was not a distraction during the webcast.

He recommended a few books for additional reading:

Refactoring: Improving the Design of Existing Code by Martin Fowler
Refactoring to Patterns by Joshua Kerievsky
Working Effectively with Legacy Code by Michael Feathers

He also recommended the Refactoring.com website, which is basically the main place to go for refactoring information.

Refactoring.com

If you are looking for a great introduction to refactoring, I highly recommend the webcast.

Refactor! for Visual Basic 2005 Beta 2 - Refactoring Tools for Visual Basic 2005 .NET

Dave Hayden — Thu, 21 Apr 2005 16:07:00 GMT

Good news for Visual Basic developers - Visual Basic 2005 will come with the Refactor! Community Edition by Developer Express. Visual C# has quite a bit of refactoring built-in, so this isn't really a huge priority for Visual C# developers. I will be using JetBrain's ReSharper anyway, so I could really care less if Visual C# 2005 had refactoring or not :)

Visual Basic 2005 RefactoringRefactor! for Visual Basic 2005 Beta 2

Refactor! for Visual Basic 2005 Beta 2 is a free plug-in from Developer Express Inc. that enables Visual Basic developers to simplify and re-structure source code, making it easier to read and less costly to maintain. Refactor! supports more than 15 individual refactoring features, including operations like Reorder Parameters, Extract Method, Encapsulate Field and Create Overload.

More and more developers are recognizing that simple, easy-to-read code is the key to application flexibility and easy maintenance. Managers are realizing that easy maintenance means low cost maintenance. If you know in your heart that parts of your code base could be better, but uncertainty about maintenance cost or concerns over breaking code have kept you from cleaning up your house, then Refactor! is for you. Refactor vaporizes barriers to code simplification, dramatically reducing the cost traditionally associated with improving, simplifying, and refactoring existing code.

To perform an extract method, just select the block of code you want to extract, and press the Refactor Key.
To reorder parameters, place the cursor on the type of the parameter and press the Refactor Key.
To create a method overload, place the cursor at the start of the method declaration and press the Refactor Key.
To reverse a conditional or replace a nested conditional with a guard clause, place the cursor on the "if" keyword and press the Refactor Key.

No other code simplification and refactoring tool is able to provide so much functionality with just one key. Refactor is the only refactoring and code simplification tool with one-key refactoring. [Microsoft]

A couple of posts on refactoring:

Refactoring to Patterns - Benefits and Motivation for Refactoring

Dave Hayden — Tue, 21 Dec 2004 23:40:00 GMT

The second chapter of Refactoring to Patterns has a short introduction to Refactoring. I already posted a short introduction to refactoring from Applying UML and Patterns.

The book describes 3 main motivations for refactoring:

Make it easier to add new code
Improve the design of existing code
Gain a better understanding of code

One of the goals of refactoring is to produce human-readable code. If you find yourself writing a lot of comments within your code to explain what it does, you may want to spend time refactoring the code so it is understandable on its own. Martin Fowler said it best:

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

The key to refactoring is that you basically refactor as you code and that you refactor in small steps. If you keep putting off refactoring, you end up getting design debt (code smells) that will probably never go away, because it is difficult to justify to the boss to spend 2 - 3 weeks worth of refactoring after the fact.

You refactor in small steps so you don't end up adding defects into the system that may take you hours to untangle. After each refactoring you re-run your unit tests to verify your refactoring did not cause a defect in the system. You then continue the cycle of refactoring and re-running unit tests until you have eliminated the code smells.

There you have it - a short introduction :)

Refactoring to Patterns - Thoughts on Test-Driven Development and Design Patterns and Extreme Programming

Dave Hayden — Sun, 19 Dec 2004 12:04:00 GMT

Joshua Kerievsky, the author of Refactoring to Patterns, appears to be a practitioner of Extreme Programming. In the first chapter of Refactoring to Patterns, Why I Wrote This Book, Joshua talks a lot about how test-driven development, refactoring, and iterative development have impacted not only the way he develops applications, but also looks at design patterns.

Design patterns are typically thought about upfront when designing an application in anticipation of problems. You immediately start applying design patterns based on unknown requirements to make the system as flexible as possible. In some cases, you are essentially applying a sledgehammer to a problem that may only require a few small taps by a regular hammer.

Instead of thinking about design patterns as solutions to anticipated problems ( initial design ), design patterns are more richly understood during the refactoring process as solutions to problems that occur during the course of refactoring. Design patterns are solutions to problems as they occur, not solutions to problems we think may occur! Excellent point, Joshua.

Two sentences really stood out in the chapter about evolutionary design that deserve a highlight:

“To date, our software design literature has focused more on teaching great solutions than on teaching evolutions to great solutions.”

Hmm.... It's a great point. The value in seeing a great solution is not so much in the solution itself, but the wealth of knowledge often lost in how the architects and developers arrived at the great solution.

“If you want to get the most out of patterns, you must ... See patterns in the context of refactoring, not just as reusable elements that exist apart from refactoring.” This is where the book Refactoring to Patterns comes in to play.

Yep, I am excited about this book!

Refactoring to Patterns and Effective C# .NET Development Books for Christmas

Dave Hayden — Sun, 19 Dec 2004 11:06:00 GMT

My wife gave me two new books for Christmas:

Refactoring to Patterns by Joshua Kerievsky
Effective C#, 50 Specific Ways to Improve Your C# by Bill Wagner

She gave them to me early because I have been looking around for a new book to replace the recently finished Applying UML and Patterns by Craig Larman.

By coincidence, I mentioned Refactoring to Patterns in a recent post: Refactoring - Code Smells - Refactoring Patterns. Refactoring to Patterns seems well recommended in the development community along with Refactoring: Improving the Design of Existing Code by Martin Fowler. I have not read the Fowler book, but it doesn't seem to be a prerequisite, more of a nice to have :)

I have read the first 7 (of 50) items of Effective C# by Bill Wagner and it is a fun read. The presentation of the ideas are short, to the point, and very useful. I love these kinds of books, because they give you real-world information that often must come from experience and is rarely mentioned in blogs and almost never found in examples and tutorials.

I will talk more about these books in subsequent posts as I read them further.