Scribd
Upload
28 views4 pages

Refactoring Practice

We thank you for completing the survey. Your responses have been recorded. The summary is 3 sentences or less.

Uploaded by

Jenny Liu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
28 views4 pages

Refactoring Practice

We thank you for completing the survey. Your responses have been recorded. The summary is 3 sentences or less.

Uploaded by

Jenny Liu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

We thank you for your time spent taking this survey.

Your response has been recorded.

Below is a summary of your responses Download PDF

Welcome to the Refactoring study form!

Tell us your CSID so you can get credit

j7h2b

Tell us your CWL so you can get credit

liujenn

Tell us your Name so you can get credit

Jenny Liu

What's your goal in submitting this form:

just doing it for credit, not really looking at the questions right now (by selecting this, you will get credit, but you will not
see the questions -- come back later for real practice!)

actually practicing
looking at the questions, but not entering anything for real right now

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
divergent change

complicated conditionals
switch statement/type conditionals Comments
Method too long

You know your method has feature envy when...

Your method uses no local fields but does use 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

Consider the following method:

void printOwing() {
printBanner();

//print details
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 first 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

There is no second method

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

printBanner()

"name"
name

"amount"
getOutstanding()

No it doesn't
There is no second method

Consider the following method:

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 misspelled elsewhere in the code

Powered by Qualtrics A

You might also like