在實際的項目開發中我們可能經常要修改已有的代碼，可能我們經常說開閉原則對已有的代碼不準修改，但是實際上很難，那么下面的3種方法也許能幫助我們改善對代碼的修改。
有時候在我們開發的時候需要像系統加入新的功能時候這個時候我們就可能改變我們原有方法的結構。那么下面有一個簡單例子
以前添加用戶的業務
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：把新生的方法采用受保護的虛方法，因為這樣可以加入測試（如果條件不允許的話就可以放棄對老代碼的測試）
優點：新老代碼隔離，即使是無法對老代碼進行測試，那么新加上的代碼可以進行測試。
缺點：暫時放棄了老的代碼，你基本不在為他編寫測試也不會對他進行改善。
這個和上面一個很相似。同樣我們需要向一個現存的方法添加行為，這個很容易實現，但是如果我們的項目本身沒有單元測試這個就變得很危險。在早期的設計我們的目的肯定是做一個單一的功能，但是由于業務的需要導致這個現存的方法變得越來越膨脹，而且耦合度極高，沒有接縫，那么我們就無法進行分離。所以我們可以采取包裝方法的模式來應對業務的改變
比喻我們原來的代碼只是添加員工（下面只是簡單例子，實際肯定比這復雜）
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：在引入接縫的同時加入了添的邏輯
其實包裝類采用的是組合模式，把原來的舊的類重新進行包裝，然后導入新添加行為的類中，這樣就可以添加新的行為但是卻沒有破壞舊類的行為。舉一個簡單例子
public class LogEmplyee { private Employee e; public LogEmplyee(Employee employee) { e = employee; } public void AddEmployee(UserInfo userInfo) { e.Add(userInfo); AddLog(userInfo); } }
其實這采用也是我們經常說的裝飾模式。
什么情況下我們使用包裝類
1：我們舊的類已經很大了，實在不想讓他繼續膨脹
2：我們添加新的行為很多，并且大多使用了舊類中的方法，并且有先后順序，我們就可以考慮
小結：通過上面三種方式，我們可以使他們來修改代碼，而不需要為現存的類編寫測試，當時從設計的角度來考慮確實不是很好理解，但是這么做起碼讓我們來改善我們的設計了，我們把新方法和舊方法進行了隔離，我們留下了接縫以后后期需要測試我們可以加入測試，來為我們的代碼提供保障。慢慢一點點的改變相信會使代碼變得更好。
新聞熱點
疑難解答
