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 Person(false);
   }

}

Benefits: Avoid the complexity of subclassing

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

      b. You can even refactor other’s code when trying to understand it

3. When to Refactor

   a. Don’t set aside time to do refactoring. Instead do refactoring only because you want to do something else better.

   b. So when?

      i. I’m adding a new feature and I need to understand the existing code.

      ii.I’m adding a new feature but existing code is hard for me to do that

      iii. We are doing code review and we received a suggestion. We refactor the code to implement the suggestion to see whether it works.

4. Problems of re-factoring

   a. DB is hard to refactor

   b. Changing Publised Interface is not Easy (Web Service Interface, etc.)

      i. In this case, provide the new method while retaining the old one (Deprecate it)

     ii. Try not to publish interfaces if not required     

5. Refactoring as an Alternative to Upfront Design

   a. Strict Upfront Design doesn’t work because problems usually show up when coding

   b. Programming and refactoring without any upfront design can work but it is not the most efficeint way

   c. The right way to go: Do some upfront design to have a plausible solution, then refactor

   d. Q: Shall I have a flexible solution for this feature? 

      A: What if I just have a simple solution here? If it is easy for me to refactor the simple solution to a flexible solution in the future, then we stick to the simple solution; Or else, we create a flexible version now.

     

6. Refactoring & Performance

    Refactoring may lead to slow software since it introduces more indirection, however, it makes the software easier to tune because it leads to finer granularity, which helps you find the exact hot spot.