必会重构技巧(五):划分职责
2013-02-05 10:48
134 查看
划分职责:根据方法实现的逻辑来安排方法所在的类。
举例理解:这个重构的方法是对单一职责原则(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的责任。
举例理解:这个重构的方法是对单一职责原则(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的责任。
相关文章推荐
- 必会重构技巧(五):划分职责
- Eclipse 快捷键技巧 + 重构
- 重读模式与架构(2)——层次划分的依据和角色职责
- 31天重构学习笔记14. 分离职责
- 必会重构技巧(一):封装集合
- ios中的代码重构技巧-实用!
- 代码重构技巧
- 重构的技巧--cocoa china
- 重构-使代码更简洁优美:实际经验之谈(提供一技巧,让你省掉N多代码)
- Nginx配置相关结构划分的技巧
- css 小经验: 重构css的优化与技巧
- eclispe技巧全解(包括代码重构,调试,快捷方式)
- 用block 代替类继承实现方法的多态性重构技巧分享
- 31天重构学习笔记14. 分离职责
- 必会重构技巧(二):使用多态替换条件
- 交易系统模块划分,模块拆分,设计,重构实战.状态
- 代码重构之DAO扮演多个职责的重构案例
- 31天重构指南之十四:分离职责
- IntelliJ IDEA 复杂的重构技巧(二)
- 个人重构——职责链模式PK状态模式