Refactoring

Throughout this book, I have stressed refactoring, so it would only make sense that I practice what I preach. Indeed, a lot of the code has been refactored between Chapter 5 and this chapter.

As I mentioned earlier, refactoring is not a new concept; what is relatively new is the term itself, which was coined by Martin Fowler (refactoring.com). Refactoring is the process of improving the internal implementation of a code without impacting (or minimally impacting) the external interface. This is something developers do daily and have been doing for years; now we just have a common term to express this practice.

Appendix B shows some of the code that was refactored over the course of Chapters 5, 7, and this chapter. This reflects how things work in real life! In other words, we refactor code over a period of time as we discover better ways to improve it.

Examples of Refactoring in Our Sample Application

The following are a few examples of the type of refactoring I did to the Java and JSP code of Time Expression. Allow me to reemphasize that refactoring is not rocket science or an earth-shattering technique, so some of these might seem simple or obvious ways of improving code, but they demonstrate the very nature of refactoringthat is, improving code.

Note

Appendix B demonstrates many of the refactoring-related code changes mentioned next.

Java Refactoring Examples

The following are a few Java code-related refactoring examples for Time Expression:

• Programmatic to declarative transaction management As we discussed previously, integrating Hibernate with Spring required significant refactoring to our three manager classes.

• Extract superclass The refactoring.com website lists "Extract Superclass" as a refactoring type; the definition is as follows: "You have two classes with similar features. Create a superclass and move the common features to the superclass." We did just this for our JUnit parent test case class named TimexTestCase (discussed earlier).

• Move method I moved the getCurrentPeriodEndingDate from TimesheetListController to DateUtil because I needed this method in multiple places and it made sense to put it in a common utility class. This is referred to as Move Method on refactoring.com.

• Move class I originally placed ReminderEmail in the util package; however, I ended up moving it to the job package because that was a more appropriate place for this class.

• Removed unused variables Thanks to Eclipse's warning about unused Java elements, when we got to Chapter 8, "The Eclipse Phenomenon!" I realized I had some unused variables and import statements. I removed many of these without impacting the external interface of these classes or methods.

JSP Refactoring

The following list describes some JSP-related refactoring I had to do.

• Moved error message for JSP in a common include file Because I was duplicating the display of error and status messages, I moved it to a common file named includemessages.jsp and included it in the files that required it (for example, enterhours.jsp, timesheetlist.jsp, and signin.jsp).

• Changed to displaytag Upon discovering a better way to display and sort HTML tables, I moved all the code to the Displaytag library instead of using JSTL. This also demonstrates a key benefit of the MVC design patternthat is, we were able to change the view without impacting the model.

Refactor Mercilessly but...Save a Code Snapshot

You might have heard the term refactor mercilessly; this is one of the principles of extreme programming (extremeprogramming.org). I tend to agree with this but would also caution you to save a snapshot of your code either in a source code repository such as CVS or keep a copy of your working code in a separate directory. This enables you to roll back to your working code if your refactoring doesn't work out as you had hoped. For example, there was a point in this book where I extensively refactored some code to give something new a try. However, it didn't work out as I planned, so I was able to quickly revert to the previously saved snapshot of code. Eclipse's Local History option (discussed in Chapter 8) can also be used to restore your previous code.

Online Refactoring Catalogs (refactoring.com and agiledata.org)

Refactoring doesn't just happen with code, it can also be done at the database level.

For code-related refactoring, visit refactoring.com; it has a growing catalog of refactoring techniques (almost 100 at the time of this writing).

For database-refactoring techniques, check out agiledata.org. This, too, boasts a long list of common database-refactoring techniques (almost 70 at the time of this writing).

You might find that you are already using many of these refactoring techniques.

A Note About Refactoring in Eclipse

As we discussed briefly in Chapter 8, Eclipse provides several Java code refactoring options.

For example, for the Spring and Hibernate integration demo (in the springhibernate/ directory) we discussed earlier in the chapter, I used Eclipse's Extract Interface refactoring menu option and was able to have Eclipse automatically create an interface file for me and have the concrete classes implement this interface.