The following URLs contains some patterns that are members of a more complex pattern language. The goal of these patterns is to help people to understand HOW to refactor their programs.

These patterns were already published in two seminars and one international event (Informatics'2005, Havana, Cuba). I'm currently refining them to include the complete language in a comming AW book.

Please, I would appreciate all the help (and light) you can bring me. Post the comments here.

Thanks in advance.


- Backtrack If Refactoring Fails
http://svpino.blogspot.com/2005/10/backtrack-if-refactoring-fails.html

- The First Refactoring Step
http://svpino.blogspot.com/2005/10/first-refactoring-step.html

- Refactoring In Very Small Steps
http://svpino.blogspot.com/2005/10/refactoring-in-very-small-steps.html

- Test Every Refactoring
http://svpino.blogspot.com/2005/10/test-every-refactoring.html

- Refactoring Using Tools
http://svpino.blogspot.com/2005/10/refactoring-using-tools.html

Well, first of all thanks for consolidating such good information for users on refactoring. I will add my one experience of refactoring to this. In a code when you want to refactor specially flag variables, you need to confirm each and every occurance and consider its scope. Previously I used to use the Search/Find feature of editor, then I moved to Eclipse. Eclipse refactor doesn't only reduce whole operation to few clicks but it takes care of all issues like scope of variable and its multiple occurances.

Please share your experiences as well, so that we can avoid such mistakes in future.

for developpers that have coded like pigs...
  import java.pigs.*;

it's hard to make them learn "with patterns" so it's better to start with their "ugly" code and show how it can be improved

these 2 books try to do so :
   http://agileskills.org/
   http://www.martinfowler.com/books.html#refactoring

I agree with you that the best way to make developers learn refactoring is with the form of

ugly code --> clean code after refactoring

but my intention isn't instruct developers about the mechanics of refactoring but HOW, WHEN, WHERE and WHAT is refactoring. This is why I use patterns. If you look carefully to a couple of patterns I've published previously, you will discover that they do not include source code because they existence is not bind to any language neither code. These patterns will show another kind of valuable information.

Thanks for your comments.

Any technical comment?

IMHO what you are calling Patterns here are actually Processes executed before,during and after refactoring. It is a good checklist, but I'm afraid you are trying to fit refactoring activities into the pattern mold. Perhaps you could call them "Refactoring Process Patterns" ?

I would also like to see emphasis on continuous refactoring in your list. There is a dangerously fast growing perception that refactoring is a one-time effort.

-Ajith Kallambella.

Good general information posted - these are certainly common sense approaches to refactoring. I find myself following the process/patterns described.

I certainly agree that these are not design patterns yet the material is presented as such.

Eclipse gives good support for refactoring. You can try
this simple method extract functionality in eclipse.

1. Select few statements within a method,
2. Right Click --> Refactor --> ExtractMethod --> Give a
method name and click OK, it automatically creates the
Method parameters according to selection.

Will post few more refactor tips if interested

Refactorings like Patterns solve particular problems. Patterns however also model common structures and life cycles amongst types. Refactorings seem to deal heavily in smaller elements than types. (functions or methods where much complex "stinky" code happens). I think refactorings are more "techniques" but all the same it is great that there is more documentation and thought about the relationship here between Patterns and refactorings as there are definite "idea overlaps" there. Thank you for the great info.

Good work Santiago. I guess this will some real examples will be very helpful and will reach the developers in a quick efficient way. Also, it is not a bad idea to show UML diagrams before and after refactoring. Cheers... VJ