理解:
当你的代码中有很深的嵌套条件时,花括号就会在代码中形成一个长长的箭头。我们经常在不同的代码中看到这种情况,并且这种情况也会扰乱代码的可读性。
如下代码所示,HasAccess方法里面包含一些嵌套条件,如果再加一些条件或者增加复杂度,那么代码就很可能出现几个问题:1,可读性差。 2,很容易出现异常。 3,性能较差。
详解:重构前代码:
1 { 2 public ISecurityChecker SecurityChecker { get; set; } 3 4 public Security(ISecurityChecker securityChecker) 5 { 6 SecurityChecker = securityChecker; 7 } 8 9 public bool HasAccess(User user, Permission permission, IEnumerable<Permission> exemptions) 10 { 11 bool hasPermission = false; 12 13 if (user != null) 14 { 15 if (permission != null) 16 { 17 if (exemptions.Count() == 0) 18 { 19 if (SecurityChecker.CheckPermission(user, permission) || exemptions.Contains(permission)) 20 { 21 hasPermission = true; 22 } 23 } 24 } 25 } 26 27 return hasPermission; 28 } 29 }
那么重构上面的代码也很简单,如果有可能的话,尽量将条件从方法中移除,我们让代码在做处理任务之前先检查条件,如果条件不满足就尽快返回,不继续执行。下面是重构后的代码:
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 }
我们看到,重构了就很容易阅读了。当我们看到很长很多的代码,就不想读了,像这些清爽的代码,其实并不是有多高的技术含量,但是读起来也很舒服。我们在做复杂的处理过程时,要经常考虑这个重构。