• 31天重构指南之二十四:分解复杂判断


    今天要说的重构基于c2 wiki上的条目,你可以在这里查看该条目,在这里还有另一篇文章。

    简单的来说,当你的代码中有很深的嵌套条件时,花括号就会在代码中形成一个箭头。我经常在不同的代码中看到这种情况,并且这种情况也会引起较高的圈度复杂性。

    下面就的代码便是一个例子:

       1: public class Security
       2: {
       3:     public ISecurityChecker SecurityChecker { get; set; }
       4:  
       5:     public Security(ISecurityChecker securityChecker)
       6:     {
       7:         SecurityChecker = securityChecker;
       8:     }
       9:  
      10:     public bool HasAccess(User user, Permission permission, IEnumerable<Permission> exemptions)
      11:     {
      12:         bool hasPermission = false;
      13:  
      14:         if (user != null)
      15:         {
      16:             if (permission != null)
      17:             {
      18:                 if (exemptions.Count() == 0)
      19:                 {
      20:                     if (SecurityChecker.CheckPermission(user, permission) || exemptions.Contains(permission))
      21:                     {
      22:                         hasPermission = true;
      23:                     }
      24:                 }
      25:             }
      26:         }
      27:  
      28:         return hasPermission;
      29:     }
      30: }
     
    重构上面的代码也很简单,如果有可能尽量将条件从方法中移除,我们让代码在做处理任务之前先检查条件,这有些基于约定编程的味道。下面是重构后的代码:
     
       1: public class Security
       2: {
       3:     public ISecurityChecker SecurityChecker { get; set; }
       4:  
       5:     public Security(ISecurityChecker securityChecker)
       6:     {
       7:         SecurityChecker = securityChecker;
       8:     }
       9:  
      10:     public bool HasAccess(User user, Permission permission, IEnumerable<Permission> exemptions)
      11:     {
      12:         if (user == null || permission == null)
      13:             return false;
      14:  
      15:         if (exemptions.Contains(permission))
      16:             return true;
      17:  
      18:         return SecurityChecker.CheckPermission(user, permission);
      19:     }
      20: }
     
    如你所看到的,重构后的代码可读性和可维护性更好了,我们读代码时遍历程序的所有分支路径也变得简单起来了。
    原文链接:http://www.lostechies.com/blogs/sean_chambers/archive/2009/08/24/refactoring-day-24-remove-arrowhead-antipattern.aspx
  • 相关阅读:
    功能测试点总结
    SQL 注入
    软件特征功能测试过程分析 (引用)
    高效率测试之巧用策略模式 (引用)
    Oracle数据库安装过程中遇到的若干问题
    涉众利益分析
    问题账户需求分析
    2018春阅读计划
    《我们应当怎样做需求分析》阅读笔记
    个人总结
  • 原文地址:https://www.cnblogs.com/zhangronghua/p/1584651.html
Copyright © 2020-2023  润新知