tagged by: refactoring boundary
The answer to this question is pretty simple - changing an interface is a refactoring providing you change all the callers too. A great example of this is Rename Method, which is an interface changing refactoring present on pretty much all refactoring tools.
2 September 2007
Here's an interesting conundrum posed by Przemyslaw Pokrywka. One of the refactorings in the book is Introduce Null Object - a very useful refactoring (also discussed in Josh's new book.) Przemyslaw's point is that this refactoring can alter behavior. If you have a method return a null, and you invoke a method on that null you'll get a null pointer exception. If you use a Null Object you'll get some default behavior.
3 September 2004
There was some recent discussion on the refactoring mailing list about what is or isn't a refactoring. As with these discussions, there's always a danger of debating how many angels fit on a pin, but thinking about the boundaries does have some useful purpose.
The order in which you declare features in modern programming languages doesn't alter the program at all. If you swap two methods around in your text file, the program doesn't care. Thus the argument against it being a refactoring is that it doesn't change how the program works, thus it doesn't change the design, thus it can't be a refactoring.
1 September 2004
I see optimization and refactoring as two separate things, even though they often use the same transformations, and a particular transformation you do to your program may be both.
2 September 2004