Refactoring Practice Solutions

1) When you have to make a related (but not identical) change in multiple places within the same class, what code smell (or symptom) must be evident in the code (not what could be evident, but must be present):

• magic number

• one class doing the work of two

• method in the wrong class

• delocalised change

• duplicated code

• shotgun surgery << this wouldn’t be a WRONG answer because shotgun surgery can sometimes happen within the same class -- but more typically, though it may touch multiple places in the same class, it will also involve other classes.

• divergent change (this one is on the edge -- the story could HEAVILY imply that you are having to make a change to a class that doesn’t encompass its central functionality, but some slice of its functionality -- this is a super subtle point though)

• complicated conditionals

• switch statement/type conditionals

• Comments

• Method too long

You know your method has feature envy when...

• Your method uses no local fields (this one was meant to imply that it is using no LOCAL fields, but IS using fields from other classes)

• Your method is very long and doesn’t call any local methods

• Your method violates the law of demeter but also uses local fields

• Your method violates the law of demeter and uses no local fields

• Your method mostly uses fields accessed from one of the parameters or one of the local fields of the class

• Your method is only called from outside the class, and is never used locally

2) Consider the following method:

void printOwing() {

printBanner();

//print details (this line is optionally extracted)

System.out.println("name: " + name);

System.out.println("amount: " + getOutstanding());

}

You have been told you should apply the extract method refactoring (extracting one or more methods) from the printOwing method to make it clearer.

Assuming you extracted lines of code (groups or individuals) in the order they appear in the method, which lines of code do you extract into the first method you extract:

• void printOwing() {

• printBanner();

• 
  

• >>> //print details (this line is optionally extracted)

• >>> System.out.println("name: " + name);

• >>> System.out.println("amount: " + getOutstanding());

• }

what is the name of the first method you extracted:

• printOwing

• printBanner

• printDetails

• printName

• printOutstanding

Does your extracted method require any of these as parameters?

• printBanner()

• “name”

• name

• “Amount”

• getOutstanding()

• No it doesn’t

Assuming you extracted lines of code (groups or individuals) in the order they appear in the method,

Which lines of code do you extract into the Second method you extract:

• void printOwing() {

• printBanner();

• 
  

• //print details (this line is optionally extracted)

• System.out.println("name: " + name);

• System.out.println("amount: " + getOutstanding());

• }

• There is no second method

what is the name of the second method you extracted:

• printOwing

• printBanner

• printDetails

• printName

• printOutstanding

• It doesn’t exist

Does your second extracted method require any of these as parameters?

• printBanner()

• “name”

• name

• “Amount”

• getOutstanding()

• No it doesn’t

• It doesn’t exist

3)

Consider the following method in class Student:

public void enrol() {

if (enrolmentType.equals("AUDIT")) {

Auditor a = (Auditor)this;

a.getInFree();

return;

}

if (enrolmentType.equals("MAJOR")) {

Major m = (Major) this;

m.payCourseFees();

return;

}

}

What code smell(s) is/are predominantly present:

• magic number

• one class doing the work of two

• method in the wrong class

• delocalised change

• duplicated code

• shotgun surgery

• divergent change

• complicated conditionals

• switch statement/type conditionals

• Comments

• Method too long

After you have finished refactoring to fix the predominant code smell(s) (so, not including how the code might look in intermediate stages of refactoring), you would:

• Make three new classes: Some new class (called whatever you want), Auditor, Major

• Make no new classes

• Make one new class: Called whatever you want.

• Make two new methods, each of which holds the bodies of the if-statements. These methods would be in the Student class. The code inside the methods would be precisely as is currently in the if-statements.

• Make two new methods, each of which holds the bodies of the if-statements. One of these methods would be in the Auditor class, another would be in the Major class. The code inside the methods would be modified -- no temporary object variable would be needed, and only local calls would be made.

• Make two new methods, each of which holds the bodies of the if-statements. These methods would be moved to another class, and the code inside the method bodies would need to be parameterised with a Student object.

• Make a constant to hold the strings “AUDIT” and “MAJOR” so that they are not missp