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

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

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

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

    31天重构指南 24分解复杂判断

    Refactoring Day 24 : Remove Arrowhead Antipattern

    Today’s refactoring is based on the c2 wiki entry and can be found here. Los Techies own Chris Missal also did a very informative post on the antipattern that you can find here.

    Simply put, the arrowhead antipattern is when you have nested conditionals so deep that they form an arrowhead of code. I see this very often in different code bases and it makes for high cyclomatic complexity in code.

    A good example of the arrowhead antipattern can be found in this sample here:

       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: }

    Refactoring away from the arrowhead antipattern is as simple as swapping the conditionals to leave the method as soon as possible. Refactoring in this manner often starts to look like Design By Contract checks to evaluate conditions before performing the work of the method. Here is what this same method might look like after refactoring.

       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: }

    As you can see, this method is much more readable and maintainable going forward. It’s not as difficult to see all the different paths you can take through this method.

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