Rename Method

Introduction

• Good to rename methods so they’re more expressive
• Define developer translation

Issues of impact (show impact in Eclipse)

#1 Clients and test cases
Changing a method’s name impacts clients and test cases.

#2 Interface
Changing a method name on an interface impacts not only the implementing classes but their clients and test cases as well.

#3 Subclass / Superclass
Changing a method name of a subclass or superclass (overriding) impacts all the implementations, their test cases and clients. This can be of a significantly larger impact which results in an ever bigger overhead to give the method a more appropriate name.

Manual refactoring techniques

1. Follow the red dots
Rename the method and see the compilation errors show up in Eclipse or a compilation errors if you’re not using an IDE. That there is the impact annotated by those lovely red markers. Go through each red marker and correct the compilation error (update to use the new method name).

The overhead of changing the method name as you resolve compilation errors depends on the number of clients and test cases calling the updated method.

2. Finding references and implementations
Another technique is to create a new method with the new name, then copy the old method’s implementation to the newly created method. Update the old method to call the new method and then find all references to the old method and update them to use the new method. This technique is used when an incremental refactoring strategy is adopted. So, only certain clients will use the new method name.

Problems with manual refactoring
Developers are sometimes discouraged to go through with the renaming of a method when the renaming effort results in a huge impact for which the overhead of resolving referencing code outweighs the benefits of renaming to a more aptly named method. In the case a partial rename refactoring (only some clients are updated to use the new method name) the developer will not be discouraged by a huge impact overhead, since it can be controlled, but what you’re left with is a code base potentially littered with partial refactorings; methods calling other (renamed) methods pollutes the API.

Not refactoring due to the impact on the code-base is not healthy and will lead to code entropy; “oh don’t change that method”. The code will become stale and not evolve. Developer translation will still be needed, something we want to minimize.

Now, let’s see how to become a refactorKing using Eclipse
todo....