Refactoring Java Code in Eclipse

Refactoring is the process of modifying code without altering its behavior and meaning. We do refactoring to make code more understandable, easier to maintain or modify, or to bring it into conformance with our coding organizations standards. In general, the term “refactoring” is not used for trivial changes such as reformatting or altering comments, but reserve it for changes that, if done incorrectly, could actually alter the behavior of the code.

1. Start Eclipse and return to the workspace that you used in the earlier lab. Open your Pie project (if necessary) by right-clicking ion it and selecting “Open”.

2. One of the most common forms of refactoring to the renaming of things. Earlier, we renamed the “draw” function in the Pie class to “draw2”, and, in doing so, broke the code that was calling that function by its original name.

   There’s a better way to handle that sort of thing. Open the Pie.java file in the editor. Find the draw2 function. Let’s change it safely back to it’s original form. First, though, double-click on “draw2” to select the name, then use Ctrl-Shift-G to see where it is referenced. You can see that it’s used in the PieView paint function.

   With “draw2” still selected, right-click on it, and select “Refactor…Rename”. Change the name back to “draw” and hit enter. The name has now been changed, and notice the lack of any error messages. Take a look at the paint function in PieView.java. Notice that it has changed “automatically” to call “draw” instead of “draw2”.

3. Go back to Pie.java. Near the beginning of that class, you can see that we have several data members, each of which is marked “public”. The syntax is a little different, but your C++ background can pretty much tell you what that means, and you probably know that, for any non-trivial class, public data members are generally frowned upon.

   Double-click on “sliceAngle” to select it. Hit Ctrl-Shift-G to remind yourself of where this data member is currently being used (in Pie and in the trackMouse function of PieView). Now, right-click on “sliceAngle” and select “Refactor…Encapsulate field”. A box pops up to offer various options for naming and location. Select “Generate method comments” and click “OK”.

   Look at the changes. sliceAngle is now marked as private. Extrapolating from your knowledge of C++, you would expect such a change to have broken PieView. But, before checking on that, scroll down to the bottom of Pie.java and see that you now have two new functions, getSliceAngle() and setSliceAngle(). Now look at the trackMouse function of PieView. . The former assignment statement assigning a value to sliceAngle has now been replaced by a call to the newly generated setSliceAngle function.

   Try encapsulating the remaining public data member of Pie.

4. All of the classes in our project are currently in the default package. That’s OK for small programs, but it’s awkward for larger ones.

   In the Project browser, right-click and select “New…Package”. Name the package “Pastry” and click Finish. We now have a package with no contents.

5. In the Package browser, click and drag Pie.java to the new Pastry package. Now, in the editor, look at the top of Pie.java. You can see that a “package Pastry;” header line has been added. If, outside of Eclipse, you view the directory where you are keeping this project, you will discover that a directory named “Pastry” has been created and that Pie.java is now in that directory.

   Look at PieView.java. Near the top is a list of “import” statements. You might need to expand these by clicking on the circled +. Note that we now have an import of the class Pastry.Pie.

6. To see how this refactoring is different from ordinary file manipulation, use your underlying operating system (outside of Eclipse) to move the file Filling.java into the Pastry directory.

   Eclipse probably won’t notice the change right away. Right-click on the Pie project in the Package browser and select Refresh to ask Eclipse to re-examine the project directories. You can see that we now have problems.

   You should have an error message for Filling.java indicating that “The declared package ”“ does not match the expected package Pastry”. In other words, the location of the Filling.java file is inconsistent with the Java notion that package structure should match directory structure. Left-click on the error marker and Eclipse will offer to either add the correct package header or to move the file back to where it had been. Select the first option and save the file.

   Depending on what version of Java you are running, you might still have an error message. That’s because Filling is importing Pastry.Pie and you actually are not supposed to import classes from the same package that you are already in. Even if you don’t get that message, delete the “import Pastry.Pie” line to be safe.

7. Click and drag each of the classes remaining in the default package, dropping them into the Pastry package. After doing this, check them and note that they each have the appropriate package header, but that PieView no longer has an import statement for Pastry.Pie (in Java, one does not import classes that are within the same package).

8. Run the program, and see that none of the changes you have made have actually affected the behavior at all. All of them have been for the purpose of making the code cleaner, better structored, or more organized.