架构,改善程序复用性的设计~第三讲 实现一种功能的代码只能出现在一处
从标题中可以看到本篇文章将介绍代码随意性的缺点及由此引发的后果,首先,来说一下同一功能的代码在多个程序中被编写多次的后果:
1 它破坏了面向对象的“单一职责”的原则
2 当代码逻辑复杂时,或者进行二次开发时,程序员将对方法调用产生歧义,即不知道应该使用哪个方法,即代码可读性差
3 当这个不规范的方法逻辑需要修改时,你将会进行多次重复的调整,这是一个程序不希望做的事
解决方法:
当几个模块需要用到同一功能,或者功能相似的方法时,应该先将公用的功能抽象成一个新的方法,再把不同的地方抽象成其它方法,这也就是《重构》中的extract method 。
下面看一下代码:
不规范的:
View Code
1 public bool RegisterUser(Userbase entity) 2 { 3 bool flag = false; 4 try 5 { 6 //注册用户逻辑 7 8 //添加日志逻辑 9 } 10 catch (Exception) 11 { 12 13 throw; 14 } 15 return flag; 16 }
规范的,再利用率高的,面向对象的:
View Code
/// <summary> 20 /// 注册用户 21 /// </summary> 22 /// <param name="entity"></param> 23 /// <returns></returns> 24 public bool RegisterUser(Userbase entity) 25 { 26 bool flag = false; 27 try 28 { 29 //注册用户逻辑 30 } 31 catch (Exception) 32 { 33 34 throw; 35 } 36 return flag; 37 } 38 /// <summary> 39 /// 添加日志 40 /// </summary> 41 /// <param name="entity"></param> 42 /// <returns></returns> 43 public bool AddLog(Log entity) 44 { 45 bool flag = false; 46 try 47 { 48 //添加日志逻辑 49 } 50 catch (Exception) 51 { 52 53 throw; 54 } 55 return flag; 56 }
通过代码我们可以看到,不规范的代码将多种功能方法合成了一种,属于逻辑混乱了,而规范的代码逻辑清晰,职责分明,代码重复利用率较高。