Refactoring Assistants Session

Introduction

In this session, we will learn about the different tools available for refactoring assistance.

We will search for design smells, symptoms of design problems that give us hints on where and how to refactor. With some tool aid, we will plan ahead the necessary refactorings that might solve these problems. Finally, we will check that the problems have been actually solved.

 CONTEXT

The context of the problem is presented in these slides.

MATERIALS

In this lab session, we will use several resources, comprising literature and tools.

References:

  • M. Fowler, K. Beck, J. Brant, W. Opdyke, and D. Roberts. Refactoring: Improving the Design of Existing Code. Object Technology Series. Addison-Wesley, 1 edition, June 1999.
  • Fowler's online refactoring Catalogue: http://www.refactoring.com/catalog/index.html
  • M. Lanza and R. Marinescu. Object-Oriented Metrics in Practice - Using Software Metrics to Characterize, Evaluate, and Improve the Design of Object-Oriented Systems. Springer, 2006.
  • In the introductory slides, you will find a diagram, extracted from the OOMP book. This diagram depicts the relationships that exist between different design smells.
  • M. Fowler and J. Kerievsky. Smells to refactorings quick reference guide. reference sheet, 2005.: http://www.industriallogic.com/blog/smells-to-refactorings-cheatsheet/

Additional references:

 TOOLS

The following tools can help you on refactoring activities (we are going to use some of them during the exercise).

  • Eclipse: The IDE contains an automated tool that more common and well-known refactorings for Java. http://www.eclipse.org  (Eclipse RCP o Classic + JDT + EMF will be enough)
  • InFusion: Design Smell detection and problem visualization tool. As we learned this semester, inFusion is not working. 
  • CodeScene: Analysis and visualization can detect smells. The Technical Debt part show refactoring targets. The Code Biomarkers show a more detail analysis of smells but is only available to paid subscribers.
  • JDeodorant: Eclipse plugin. Smell detection and correction tool. It supports these design smells: Type Checks, Feature Envy, God Class, Long Parameter. (JDeodorant brief manual)
  • JMove: Another Eclipse plugin, specialized on performing only move method refactorings. Therefore, it is a good tool to detect the Feature Envy smell.
 

 CASE STUDY

We will analyze and refactor (an older version of) GanttProject. We have prepared some prepackaged sources, that include all the needed libraries. You can grab the sources here: GanttProject source. There is also a GitHub repository with the sources for your convenience. 

Users of Eclipse Mars may have some issues to compile the project. To solve the issue: 1) select the 'Eclipse Project Updates' site (http://download.eclipse.org/eclipse/updates/4.4), 2) add 'Eclipse 2.0 Style Plugin Support' in the 'Eclipse Tests, Examples and Extras' section.

Add the project to the Workspace by:

  1. selecting Import -> General -> Existing project (Check "Copy project into workspace")
  2. Select the ganttproject folder

 Exercises

We are going to begin by manually looking for refactoring opportunities. In real projects, it is better to use CodeScene, JDeodorant, or any other refactoring tool to show refactoring candidates (and better guide your refactoring activities). For this exercise, we already have our refactoring targets.

For the first exercise, we are going to focus on Data Classes. You can search the web or read the materials to understand what this problem is about. Here is a summarized description of Data Class Smell. Warning: there are architecture designs where the usage of data classes is mandatory, therefore, not always this should be considered a bad smell (it will depend on the project and planned architecture).

Now examine the following Data Class that was detected by our tool/engineer:

CSVOptions (package src.net.sourceforge.ganttproject.io)

First, take a look at the source code.

Questions:

  • Does CSVOptions look like a DataClass?
  • Why?
 
Now, we need to further inspect this class and decide whether it should be refactored. 
  • Inspect the External Usage of Public Data: Check what classes and methods are accessing the data class (on Eclipse, right click and select References -> Project, to see the callers of the class).
  • Explore the Encapsulation View to spot the members of the class that contribute to a low degree of encapsulation.
  • Explore the Internals View to get a picture of how intensively data is used within the class itself.

Questions:

  • Is the data in CSVOptions being used more by itself or by other classes?
  • What classes are accessing the data in CSVOptions?
  • What other problems can you identify? 
 
 
Now let's see another type of design smell called Feature Envy. Read the material on this smell or search the web for it. After that, take a look at the method 

writeResourceHeaders

from the class

GanttCSVExport (package src.net.sourceforge.ganttproject.io)

Questions:

  • Does GanttCSVExport.writeResourceHeaders look like a Feature Envy method?
  • How these two entities are related?
  • Can you think of a refactoring strategy involving these two entities? Should we refactor them? Why?
 

Now, let's refactor these smells:

  • Prepare a plan of action. What changes would you apply to the system in order to remove the Data Class and the Feature Envy smell? (A principle of OO good design states that behavior and data should live together)
  • Launch Eclipse and refactor the classes in order to remove the smells. (Use code search in Eclipse to determine how to perform this refactoring) 

 

To summarise this guided case, the general procedure you should follow is:

  1. Use JDeodorant, CodeScene, or other tools to identify design smells

  2. Check the source code of the affected entity and its related entities and decide whether it is a smell or not.

  3. Try to link this detected problem with others. Try to find other design smells that are connected to this one. For example, a method that suffers from Feature Envy will be probably accessing a Data Class. 

  4. Plan ahead the refactoring(s) that you may apply to solve this problem:

  • manually
  • checking the suggestions in the literature
  • planning the refactoring proposed by tools (e.g., JDeodorant, JMove).

 

  5. Apply the refactoring:

  • automatically using refactoring tools
  • manually

  6. Run the tests to verify the applied refactorings were behavior preserving

  7. Re-run the analysis tool to check whether the design smell has been removed.

  8. Write down your proposed solution and keep it for future references. You might reuse this refactoring recipe for future similar problems.