Home › Refactoring Assistants Session

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 literaturature 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

We are using the following tools

  • 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 visualisation tool. 
  • JDeodorant: Eclipse plugin. Smell detection and correction tool. It supports these design smells: Type Checks, Feature Envy, God Class, Long Parameter. (JDeodorant brief manual)

 CASE STUDY

We will analyse and refactor GanttProject. We have prepared some prepackaged sources, that include all the needed libraries. You can grab the sources here: GanttProject source. . 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

 GUIDED CASE

Launch InFusion, load and analyse ganttfreechart. Take a look at the list of Design Smells detected, for this exercise, we are interested in Data Classes. Read the documentation or search the web to understand what this problem is about.

Now examine the detected Data Class:

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

First take a look at the source code.

Questions:

  • Does CSVOptions look like a DataClass?
  • Why?
 

To decide whether it should be refactored and how, we will use InFusion to gather more information about the class. Click on the suggestions offered by InFusion.

  • Inspect the External Usage of Public Data: Check what classes and methods are accessing the data class the most.
  • 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? Can you identify related entities suffering from other Design Smells.
 

Read the documentation about the design smell Feature Envy. Take a look at the method

writeResourceHeaders

from the class

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

Questions:

  • Does GanttCSVExport 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 DataClass smell? (A principle of OO good design states that behaviour and data should live together)
  • Launch Eclipse and refactor the Data Class in order to remove the smell. (Use code search in Eclipse to determine how to perform this refactoring)
  • Analyze the refactored system with Infusion to confirm whether the Data Class and the Feature Envy smells have been removed.
 

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

  1. Use InFusion, or JDeodorant to identify design smells
  1. Check the source code of the affected entity and its related entities and decide whether it is a smell or not.
  2. 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 DataClass.
  3. Plan ahead the refactoring / refactorings that you may apply to solve this problem:
  • manually
  • checking the suggestions in the literature
  • planning the refactoring with InFusion
  • Checking the refactoring proposed by JDeodorant
  1. Apply the refactoring:
  • with Eclipse refactoring tools
  • automatically with Deodorant
  • manually
  1. Run the tests to verify the applied refactorings were behaviour preserving
  2. Re-run the analysis tool to check whether the design smell has been removed.
  3. Write down your proposed solution and keep it for future references. You might reuse this refactoring recipe for future similar problems.