划分职责：根据方法实现的逻辑来安排方法所在的类。

　　举例理解：这个重构的方法是对单一职责原则（SRP）的贯彻，在Coding的时候，我们不仅仅需要把方法中的逻辑单一化（主要使用 Extract Method），还要把类中的方法安置合理化。比如说有个Book()的类，那么对于Book的一些操作，如增加减少书，设置书的属性那可以交给这个类做；而如另一些方法，如买书，租书就可以交给Custom()的类来处理，因为买书，租书的逻辑主体都是Custom。

　　项目实例：就个人而言，这个重构方法我觉得大家在Coding的时候都会注意到，因为谁都会把相关的方法放在一个类中；唯一可能出现的问题就是出现大神类（God Class），也就是说这个类中集合了N多的方法，在项目中经常能看到这样的类，一个类中包含对String的处理，对Cache的处理，对数组的处理，总之是所有应用类的方法都塞在了一个类中，这样写起来方便了，但是使用起来会顺手么？找一个方法要找半天，并不适合维护。所以像这种情况我们何不把这些方法按照功能分开几个类写呢？

　　上面例子的相关代码：

 

重构前

public class Book

{

　　public void PayFee(decimal fee)

　　{

　　}

　　public void RentBook(Book book, Customer customer)

　　{

　　　　customer.Books.Add(book);

　　}

　　public decimal CalculateBalance(Customer customer)

　　{

　　　　return customer.LateFees.Sum();

　　}

}

public class Customer

{

　　public IList<decimal> LateFees { get; set; }

　　public IList<Book> Books { get; set; }

}

 

　　注意，这里Custom类中没有方法。

 

重构后

public class Book

{

　　public void RentBook(Book book, Customer customer)

　　{

　　　　customer.Books.Add(book);

　　}

}

public class Customer

{

　　public IList<decimal> LateFees { get; set; }

　　public IList<Book> Books { get; set; }

　　public void PayFee(decimal fee)

　　{

　　}

　　public decimal CalculateBalance(Customer customer)

　　{

　　　　return customer.LateFees.Sum();

　　}

}

 

　　如上，把RentBook和CalculateBalance移到了Customer类中，在这个示例中，这种重构似乎没有多大的作用，毕竟仁者见仁智者见智，很多种重构有时候看来真的挺叽歪的，并且有些重构对于程序性能的提高帮助并不大。但是，重构的目的，我个人看来，主要是培养我们的一个Coding习惯，写出做可维护的，易扩展的程序是我们Coder的责任。