划分职责:根据方法实现的逻辑来安排方法所在的类。
举例理解:这个重构的方法是对单一职责原则(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的责任。