在實際的項目開發中我們可能經常要修改已有的代碼,可能我們經常說開閉原則對已有的代碼不准修改,但是實際上很難,那麼下麵的3種方法也許能幫助我們改善對代碼的修改。1:新生方法有時候在我們開發的時候需要像系統加入新的功能時候這個時候我們就可能改變我們原有方法的結構。那麼下麵有一個簡單例子以前添加用戶的.....
在實際的項目開發中我們可能經常要修改已有的代碼,可能我們經常說開閉原則對已有的代碼不准修改,但是實際上很難,那麼下麵的3種方法也許能幫助我們改善對代碼的修改。
1:新生方法
有時候在我們開發的時候需要像系統加入新的功能時候這個時候我們就可能改變我們原有方法的結構。那麼下麵有一個簡單例子
以前添加用戶的業務
public void Add(IList<UserInfo> userInfos) { if (userInfos!=null) { Controller.Add(userInfos); } }
現在用戶分級別,不同級別的存入不同的表,下麵是白金用戶的添加
public void Add(IList<UserInfo> userInfos) { if (userInfos!=null) { IList<UserInfo> mUserInfos=userInfos.ToList().FindAll(p=>p.Type=="白金").ToList(); Controller.Add(userInfos); } }
很明顯這種寫法導致新老代碼混合在一起,我們沒法對新的代碼進行測試操作。那麼我們就可以新生一個方法
public void Add(IList<UserInfo> userInfos) { if (userInfos != null) { userInfos = GetUserInfosByType(userInfos, "白金");//此處引用 Controller.Add(userInfos); } } /// <summary> /// 新生的方法 /// </summary> protected virtual IList<UserInfo> GetUserInfosByType(IList<UserInfo> userInfos, string type) { return userInfos.ToList().FindAll(p => p.Type == type).ToList(); }
這就是一個新生方法的例子。以下使我們採取的步驟:
1:確定需要修改的地方
2:確定新生方法需要向源方法返回的值(如果需要的話)
3:把新生的方法採用受保護的虛方法,因為這樣可以加入測試(如果條件不允許的話就可以放棄對老代碼的測試)
優點:新老代碼隔離,即使是無法對老代碼進行測試,那麼新加上的代碼可以進行測試。
缺點:暫時放棄了老的代碼,你基本不在為他編寫測試也不會對他進行改善。
2:包裝方法
這個和上面一個很相似。同樣我們需要向一個現存的方法添加行為,這個很容易實現,但是如果我們的項目本身沒有單元測試這個就變得很危險。在早期的設計我們的目的肯定是做一個單一的功能,但是由於業務的需要導致這個現存的方法變得越來越膨脹,而且耦合度極高,沒有接縫,那麼我們就無法進行分離。所以我們可以採取包裝方法的模式來應對業務的改變
比喻我們原來的代碼只是添加員工(下麵只是簡單例子,實際肯定比這複雜)
public void AddEmployee(UserInfo userInfo) {
....... Controller.Add(userInfo);
....... }
但是現在對於重要的信息加入操作日誌所以我採取把原來的老方法包裝成Add如下
public void AddEmployee(UserInfo userInfo) { Add(userInfo); AddLog(userInfo);//日誌操作 } public void Add(UserInfo userInfo) {
...... Controller.Add(userInfo);
...... }
我們使用包裝方式的步驟:
1:確實要修改的地方
2:修改舊方法的名字
3:在新方法調用舊方法和其他需要調用的方法
缺點:
1:新添加的邏輯無法與以前舊的方法緊密聯合在一起,在他們之前或者之
2:需要為舊方法重新命名(這個很難)可能導致代碼的可讀性變得很差
優點:
1:新的代碼變得可測
2:在引入接縫的同時加入了添的邏輯
3:包裝類
其實包裝類採用的是組合模式,把原來的舊的類重新進行包裝,然後導入新添加行為的類中,這樣就可以添加新的行為但是卻沒有破壞舊類的行為。舉一個簡單例子
public class LogEmplyee { private Employee e; public LogEmplyee(Employee employee) { e = employee; } public void AddEmployee(UserInfo userInfo) { e.Add(userInfo); AddLog(userInfo); } }
其實這採用也是我們經常說的裝飾模式。
什麼情況下我們使用包裝類
1:我們舊的類已經很大了,實在不想讓他繼續膨脹
2:我們添加新的行為很多,並且大多使用了舊類中的方法,並且有先後順序,我們就可以考慮
小結:通過上面三種方式,我們可以使他們來修改代碼,而不需要為現存的類編寫測試,當時從設計的角度來考慮確實不是很好理解,但是這麼做起碼讓我們來改善我們的設計了,我們把新方法和舊方法進行了隔離,我們留下了接縫以後後期需要測試我們可以加入測試,來為我們的代碼提供保障。慢慢一點點的改變相信會使代碼變得更好。