Refactoring bliki

A RefactoringBoundary.

Is changing the interface of part of the code a refactoring?

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.

The changing of all the callers is an essential part of this refactoring. Just changing an interface declaration will break the system - and thus isn't a behavior preserving change.

Interface changing refactorings do assume that you can get hold of all the callers, which is why you have to be much more careful with PublishedInterfaces. With a published interface, the interface itself is part of the observable behavior of the system.

Dynamic languages can make these changes much more awkward. Static typing really does help here in pinning down exactly which interface is being called at various points. Reflective calls that can also make it harder to find, either by embedding method names in strings or even composing them at run-time. This is another area where tests are essential even in environments that have refactoring tools.

It looks like those devious people at UIUC getting ready to refactor Fortran. Brian Foote writes about the project in his unparallelled style. (He's one of the most amusing writers in software - but getting him to write anything is usually like trying to pull teeth from a live sabre-tooth tiger while wearing a necklace of freshly killed lamb chops.) (Yes I know it's old news, but I saw something else on his blog and then found this.)

A RefactoringBoundary.

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.

Now many refactorings do alter behavior, indeed they are intended to. If you apply Form Template Method, then the program works differently. The key question is whether this is what in my DefinitionOfRefactoring I called observable behavior. That is does it change what the program essentially does? With Introduce Null Object you have to look around the program for places that manipulate returned references, typically by checking to see if it's null. This is what makes this a rather tricky refactoring.

The interesting part of the conundrum is what happens if you miss an area where there's a bug. Somewhere in your program you invoke a method on a null reference. Before the refactoring you'd get an exception, we'll assume here it's one that you don't know about and goes all the way up to some top level handler. After the refactoring you get the default behavior - which may in fact fix the bug. If you fix a bug you don't know about is this still a refactoring?

I'd argue yes, since you didn't know or care (enough) about the buggy behavior then I'd say that behavior wasn't observable. Even if you knew about the bug, I'd still argue that it's okay to call this a refactoring if the bug wasn't behavior you cared about preserving.

This is an interesting case, and I could easily imagine myself changing my mind or exploring more edge cases.

One of the interesting things it points out is the difference between manual and tool driven refactoring. With manual refactoring you can make judgement calls like this, tools often have to be much more careful. Yet even tools can't always guarantee to preserve behavior - even a rename method can be break on refactoring if that method is called by reflection with a name that's read from a file.

A RefactoringBoundary.

If you make a change to improve the performance of a program, is this a refactoring?

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.

The reason I see them as different is because they have a different purpose. You do refactoring to make the code easier to understand, you do optimization to make it go faster. Introducing a variable (for example) could be done for either purpose, but depending on how you do it you are primarily doing one or the other. When you are refactoring you are thinking about making the code clearer. Your judgement on whether it's successful is based on your (subjective) assessment of whether the change makes the program easier to understand. When you are optimizing you are thinking about performance. You should be using a profiler, before and after the change to ensure that your optimization really did help performance. If the situation is performance critical you should keep a log of your change so you can retest its effectiveness when your environment (compiler, VM etc) changes later on.

So although the two are similar, and share many transformations, I see them as different because their purpose is different.

A RefactoringBoundary.

Is it a refactoring to change the order of declarations, eg methods and fields in a Java program?

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.

In my DefinitionOfRefactoring, I used the phrase "to make it easier to understand and cheaper to modify". Can changing declarations do this? In some cases I think it does. It can make sense to put related features in a class together. You can also order the features in such a way to help explain how the class works - this is particularly valuable when you writing test cases (although here, in some xunit implementations, the order might affect the execution). So since it improves the understandability of the code, I would count reordering declarations as a refactoring.

The fact that it doesn't alter the internal execution is a red-herring. Changing the name of a method doesn't alter the execution, yet renaming is a very important refactoring to improve the understandability of a program.

Once a term known to only a few, "Refactoring" is commonly tossed around the computer industry. I like to think that I'm partly responsible for this and hope it's improved some programmers lives and some business's bottom lines. (Important point, I'm not the father or the inventor of refactoring - just a documenter.)

However refactoring is often used when it's not appropriate. If somebody talks about a system being broken for a couple of days while they are refactoring, you can be pretty sure they are not refactoring. If someone talks about refactoring a document, then that's not refactoring. Both of these are restructuring.

I see refactoring as a very specific technique to do the more general activity of restructuring. Restructuring is any rearrangement of parts of a whole. It's a very general term that doesn't imply any particular way of doing the restructuring.

Refactoring is a very specific technique, founded on using small behavior-preserving transformations (themselves called refactorings). If you are doing refactoring your system should not be broken for more than a few minutes at a time, and I don't see how you do it on something that doesn't have a well defined behavior.

I realize I may be fighting a losing game here, but I do want to preserve the precision of the word refactoring. There may be other good techniques for restructuring, but they are different. I'd like us to be clear about what we mean when we use this word.