徐州软件开发网、徐州程序员、徐州程序员招聘求职、徐州软件企业推荐、 软件项目交易。点击注册加入我们,进入论坛发布消息

【行动胜于雄辩】徐州程序员交流QQ群:324379(一群,满)1182709(二群).进群请先看公告! 招聘求职请先在本站'招聘\求职区'发布,只在群里发布的,将被请出程序员交流群! 谢谢合作

本主题共有 0 篇回复,最新回复发表于 10-10-2009 22:18,作者 xzsdn_08
页 1 / 1 (1 项)
帖子排序: 上一主题 下一主题
  • 10-10-2009 22:18

    • xzsdn_08
    • 灌水10强
      男
    • 注册时间 01-04-2009
    • 江苏徐州
    • 发帖总数 641

    31天重构指南 27去除上帝类

    Refactoring Day 27 : Remove God Classes

    Often with legacy code bases I will often come across classes that are clear SRP violations. Often these classes will be suffixed with either “Utils” or “Manager”. Sometimes they don’t have this indication and are just classes with multiple grouped pieces of functionality. Another good indicator of a God class is methods grouped together with using statements or comments into seperate roles that this one class is performing.

    Over time, these classes become a dumping ground for a method that someone doesn’t have time/want to put in the proper class. The refactoring for situations like these is to break apart the methods into distinct classes that are responsible for specific roles.

       1: public class CustomerService
       2: {
       3:     public decimal CalculateOrderDiscount(IEnumerable<Product> products, Customer customer)
       4:     {
       5:         // do work
       6:     }
       7:  
       8:     public bool CustomerIsValid(Customer customer, Order order)
       9:     {
      10:         // do work
      11:     }
      12:  
      13:     public IEnumerable<string> GatherOrderErrors(IEnumerable<Product> products, Customer customer)
      14:     {
      15:         // do work
      16:     }
      17:  
      18:     public void Register(Customer customer)
      19:     {
      20:         // do work
      21:     }
      22:  
      23:     public void ForgotPassword(Customer customer)
      24:     {
      25:         // do work
      26:     }
      27: }

    The refactoring for this is very straight forward. Simply take the related methods and place them in specific classes that match their responsibility. This makes them much finer grained and defined in what they do and make future maintenance much easier. Here is the end result of splitting up the methods above into two distinct classes.

       1: public class CustomerOrderService
       2: {
       3:     public decimal CalculateOrderDiscount(IEnumerable<Product> products, Customer customer)
       4:     {
       5:         // do work
       6:     }
       7:  
       8:     public bool CustomerIsValid(Customer customer, Order order)
       9:     {
      10:         // do work
      11:     }
      12:  
      13:     public IEnumerable<string> GatherOrderErrors(IEnumerable<Product> products, Customer customer)
      14:     {
      15:         // do work
      16:     }
      17: }
      18:  
      19: public class CustomerRegistrationService
      20: {
      21:  
      22:     public void Register(Customer customer)
      23:     {
      24:         // do work
      25:     }
      26:  
      27:     public void ForgotPassword(Customer customer)
      28:     {
      29:         // do work
      30:     }
      31: }

    This is part of the 31 Days of Refactoring series. For a full list of Refactorings please see the original introductory post.

页 1 / 1 (1 项)
徐州软件开发网、徐州软件开发社区、徐州程序员
© Copyright 2008-2011 XZSDN.NET   Powered By communityserver   站长博客 我的Blog
苏ICP备09002379号 | 意见反馈 | 联系我