Refactorings for Switch Statement

Fowler has defined two composite refactorings called Replace Conditional with

Polymorphism and Replace Type Code with Subclasses. Such refactorings

are to be used to remove bad switch statements. ForReplace Conditional with Polymorphism, a list of statements in each case are extracted to create an overriding method in the corresponding subclass. A switch statement is removed and the original method is made abstract. Nonetheless, it may be necessary to first apply Replace Type Code with Subclasses, if no subclasses are defined. This refactoring creates a subclass for each case in switch statement. Figure 4.9 illustrates the code after applying both refactoring in attempts to remove a switch statement from Figure 4.6. It is worth noting that the design may not be optimal after the switch state- ment is removed. More transformations may be necessary depending on the body of each case in the switch statement. For instance, the code in Figure 4.9 can be further improved by adding a new field fee per credit which leads to duplicates in getTuition method. Such methods can be move to class Student as discussed in Section 4.1. The final code after the transformations is depicted in Figure 4.10. This research only attempts to remove a switch statement that is used in place of polymorphism. We do not intend to provide the algorithm that will yield an optimal design. Further improvements on the code’s structure are left to the developer to carry out himself.

abstract class Student {

static double segregated_fee = 300; private int num_credits;

abstract public static double getTuition(); }

class Undergraduate extends Student {

...

public static double getTuition() {

return segregated_fee + 300 * num_credits; }

}

class Graduate extends Student {

...

public static double getTuition() {

return segregated_fee + 350 * num_credits; }

}

class Dissertator extends Student {

...

public static double getTuition() {

return segregated_fee + 200 * num_credits; }

}

Figure 4.9: Remove Switch Statement

4.5

Summary

This chapter has described the code smells studied for this dissertation as well as the sequence of refactorings that can be applied to remove each code smell. We also pro- vide algorithms for detecting each smell. In particular, this work uses an AST-based algorithm to detect duplicated code which cannot detect clones created by statement reordering. Data class and switch statement detections are also performed on the AST. As data classes contains only the fields, accessors and mutators, the detection algorithm is rather straightforward. Detecting wrong use of switch statements, on the other hand, is very complicated and difficult. The approach for feature envy detection

abstract class Student {

static double segregated_fee = 300; private int num_credits;

private double fee_per_credit;

public static double getTuition() {

return segregated_fee + fee_per_credit * num_credits; }

}

class Undergraduate extends Student {

public Undergraduate(int c) {

fee_per_credit = 300; num_credits = c; }

}

class Graduate extends Student {

public Graduate(int c) {

fee_per_credit = 350; num_credits = c; }

}

class Dissertator extends Student {

public Dissertator(int c) {

fee_per_credit = 200; num_credits = c; }

}

Figure 4.10: A More Desirable Result is discussed in the next chapter.

As we mentioned in the beginning of this chapter that this work focuses on a partial set of code smells. Many researchers work on detection algorithms for other smells. For instance, a number of research works [96, 63] discuss how to identify fragments of code in the long method needed to be extracted. Their approach does not just detect the code smell but also scope down the region of problematic code such which is more useful to the developer. It does not only identify where the problem is but it also provides suggestions on how to fix it.

Chapter 5

Metric for Feature Envy Detection

In object-oriented systems, classes group data and related operations within a spe- cific domain concept, and support object-oriented features such as data abstraction, encapsulation and inheritance. Many researchers have proposed metrics to measure object-oriented software qualities. Such qualities include but are not limited to cou- pling and cohesion. This work focuses on code smells that indicate poor OO designs with respect to coupling and cohesion therefore only measurements of coupling and cohesion will be discussed here. Du Bois and his colleagues [10] provide discussions on how refactoring can improve coupling and cohesion in software systems.

5.1

Coupling Measures

Low coupling between objects is desirable for modular programming. A measure of coupling is useful in identifying an improper relationship between objects. In order to improve modularity and promote encapsulation, the relationship between classes

should be kept to a minimum. The higher the coupling, the higher the sensitivity to changes in other parts of the system. A small premeditated change in a highly coupled system could progress into a long series of unanticipated changes which makes it more difficult to maintain the system.

Previously, coupling is defined subjectively which make it difficult to use in prac- tice. Chidamber and Kemerer [14] was among the first who defined a metric to mea- sure the coupling between objects. Specifically, their metric are called CBO (coupling between objects). According to their definition, two classes are coupled when methods declared in one class use methods or instance variables defined by the other classes. CBO is well known and is widely used in many software industries.

Myer introduced a much more complicated metric. Coupling is defined in six lev- els. Such coupling levels are used to measure the interdependence of two modules [68]. Page-Jones extends Myer’s work by ordering the coupling levels based on their effects on maintainability, understandability and reusability [75]. If two modules are coupled in more than one way, they are strongly connected and are considered to be coupled at the highest level. In addition to the Myer’s six coupling levels, Offuttet al. added the zeroth level of coupling for modules that are independent [71]. There are many other approaches to measure coupling not discussed in this work.

Many metrics discussed here can be automated but their computations are done on the source code and require the code to be written beforehand. Some metrics can be computed from the design of the software which allow the software qualities to be measured before starting the implementation [51, 87, 50].