Before Refactor if(age < 60 && age >= 50){ salary = age*10 + 100; }else{ salary = age*5; } After Refactor if(isMidAge(age)){ salary = midAgeSalary(age); }else{ salary = nonMidAgeSalary(age); } Benefits: You hightlight the condiction and make it clear what you are branching on.

Before Refactor class Person{ boolean isMale(){} } class Male extends Person{ boolean isMale(){ return true; } } class Female extends Person{ boolean isMale(){ return false; } } After Refactor class Person{ private boolean male; private Person(male){ this.male = male; } boolean isMale(){ return male; } Person createMale(){ return new Person(true); } Person createFemale(){ return new […]

Before Refactor static final int MAN = 1; static final int WOMAN = 2; After Refactor  — Option1 enum Gender{ MAN, WOMAN } After Refactor  — Option2 class Gender{ static final Gender MAN = new Gender(1); static final Gender WOMAN = new Gender(2); private Gender(int value){ } } Benefits: Type Safe

Before Re-factoring class Person{ Set courses; Set getCourses(){ return courses; } void setCourses(){…} } After Re-factoring class Person{ Set courses; Set getCourses(){ return Collections.unmodifiableSet(courses); } void addCourse(){…} void removeCourse(){…} } Benefits: 1. Person will know it when courses changes. 2. Coupling between clients which call Person and courses will be reduced.

Before Refactoring validate1(){ if(size < 2){ addError(…); } } validate2(){ if(size < 2){ addError(…); } } After Refactoring static final int MIN_SIZE = 2; validate1(){ if(size < MIN_SIZE){ addError(…); } } validate2(){ if(size < MIN_SIZE){ addError(…); } }

Before Refactoring class Employee{ String phoneNumber; someMethod1(){ String area = phoneNumber.subString(…); } } class Employer{ String phoneNumber; someMethod2(){ String area = phoneNumber.subString(…); } } After refactoring class Employee{ Phone phoneNumber; someMethod1(){ String area = phoneNumber.extractAreaCode(); } } class Employer{ Phone phoneNumber; someMethod2(){ String area = phoneNumber.extractAreaCode(); } } class Phone{ String number; String extractAreaCode(){ … […]

When?    你有一个大方法要拆成若干个小方法。但这个大方法里有一大堆散乱的临时变量，并且它们被反复赋值，如果要拆分，就得传来传去，还要用做小方法的返回值，这样一搞代码的可读性不高。 Solution:   如果这些变量不是临时变量，而是成员变量，那么都不用传来传去，也不用用作小方法的返回值了。   然而，把这些变量用作当前对象的成员变量是不合适的。所以我们就新建一个类，然后把大方法放到这个类中，把临时变量用作这个类的成员变量，问题就解决了。

When to do it?   There is a method that is too long, or some code in which needs a comment to understand its purpose Benefits    1. Finely grained sub-methods may be reusable in the future.    2. More readable. A series of sub-methods seem like a series of comments.

1. Definition by Martin Fowler    a.The purpose of refactoring is to make the software easier to understand and modify    b.Refactoring does not change the observable behavior of the software    2. Why Refactor? To make software easier to understand       a. You can refactor it to make it more readable for future developers […]