CSC/ECE 517 Fall 2014/OSS E1455 skn

E1455: Refactoring the Chart helper

Overview

Code refactoring

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.<ref>http://refactoring.com/</ref>

References

<references/>

Project Resources

• GitHub Repository
• VCL IP

Objective

The aim of the project was to refactor the chart helper module of Expertiza. The task was to analyze the helper chart.rb which failed to follow the object oriented design principles. There were two major functions being used in the class, effectively. These two functions were performing all their operations in one single block which led to code duplication and redundancy. Our task involved removing these design errors and making it more elegant and efficient.

Files Modified

• chart.rb
• analytic_helper.rb
• analytic_controller.rb
• views/analytic/index.html.erb

Requirements

The following changes were expected,

• self.dataAdapter method
  1. Too long, needs to be divided
  2. Too many if-else statements

• self.data_template method
  1. Needs to be broken down or moved according to requirement
  2. Define each template independently instead of in the same method
  3. Remove unecessary data from :series for scatter plot
  4. Method has duplicate data. Remove the duplicate occurrences

Design Changes

To fulfill the requirements, the following changes were implemented,

Refactoring the dataAdapter method

• What it does
  

The dataAdapter function is basically an initialization function which sets parameters for the graphical plot to some default starting values based on the type of analytic view the user wants to rendered. There was quite a bit of code duplication in the existing function, especially when it came to setting parameters for some specific chart types like pie charts for instance. The code in this function violated the 'Single Responsibility Principle'.

• Original code:

• Changes made:

1. Moved code for setting optional parameters to function set_template_optional_params
2. Moved code for validation of optional parameters to function called validate_optional_conf
3. The new code does not violate the Single Responsibility Principle anymore

Refactoring the dataTemplate method

• What it does

The main purpose of this method was to set up the data templates for the different varieties of graphs - bar , scatter , pie and line namely. This method, again, was too long and executing too many different tasks in the same block of code. Furthermore, there was a lot of code duplication which did not follow object-oriented design at all. There was also hard-coded data which was not serving much purpose which we decided to prune to make the code more elegant. The original method was setting up templates for all these different types of graphs in the same method which violated the 'Single Responsibility Principle'.

• Original code:

• Changes made:

1. Created separate methods for each different plot - bar , line , pie and scatter
2. Created one method called get_generic_template to set up some common parameters which are used by more than one plot.
3. The new code does not violate the Single Responsibility Principle and also supports Separation of Concerns and Code Reuse which are both good practices when it comes to object-oriented design.