架構，改善程序復用性的設計~第三講 實現一種功能的代碼只能出現在一處

從標題中可以看到本篇文章將介紹代碼隨意性的缺點及由此引發的后果，首先，來說一下同一功能的代碼在多個程序中被編寫多次的后果：

1　　它破壞了面向對象的“單一職責”的原則

2　　當代碼邏輯復雜時，或者進行二次開發時，程序員將對方法調用產生歧義，即不知道應該使用哪個方法，即代碼可讀性差

3　　當這個不規范的方法邏輯需要修改時，你將會進行多次重復的調整，這是一個程序不希望做的事

解決方法：

當幾個模塊需要用到同一功能，或者功能相似的方法時，應該先將公用的功能抽象成一個新的方法，再把不同的地方抽象成其它方法，這也就是《重構》中的extract method 。

下面看一下代碼：

不規范的：

 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         }      

規范的，再利用率高的，面向對象的：

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

 

通過代碼我們可以看到，不規范的代碼將多種功能方法合成了一種，屬於邏輯混亂了，而規范的代碼邏輯清晰，職責分明，代碼重復利用率較高。