關鍵字：uml this._本院系報到 = p本院系報到;
this._教材科發教材 = p教材科發教材;
}
//為什么有了賦值的構造函數還要暴露這么多只寫屬性出來呢？
//這樣就可以在運行時改變高校的報到步驟了，
//假如報到系統出現故障我們可以馬上采取另外一種方案
//而不需要停止系統的運行
I教務處報到 _教務處報到;
public I教務處報到 教務處報到
{
set
{
_教務處報到 = value;
}
}
I繳費 _繳費;
public I繳費 繳費
{
set
{
_繳費 = value;
}
}
I本院系報到 _本院系報到;
public I本院系報到 本院系報到
{
set
{
_本院系報到 = value;
}
}
I教材科發教材 _教材科發教材;
public I教材科發教材 教材科發教材
{
set
{
_教材科發教材 = value;
}
}
//用上了策略模式，模板方法更加靈活了
//但現在還是不是模板方法了？
public void 報到()
{
教務處報到.教務處報到();
繳費.繳費();
本院系報到.本院系報到();
教材科發教材.教材科發教材();
}
}
代碼我就寫這么多了，要這個代碼運行起來還需要一些補充，這個高校類如何進行實例化才能更靈活也值得考慮。
看到沒，利用組合我們也可以達到代碼復用的目的，而且沒有繼承的弊端。
策略模式的副作用
上面好像都是在說策略模式的好話，那策略模式有沒有副作用呢？當然有。
一、 雖說客戶代碼無須關心各個策略是如何實現的，但是它們還是要知道有多少種策略實現，該實現是干什么的，也就是客戶代碼需要知道策略的一些細節，這樣才可以根據需要使用哪個策略，但是我們可以使用創建型模式來解決這個問題。
二、 有的時候策略需要從Context那里獲取一些數據，這樣造成雙向的關聯，而且有可能幾個策略需要的數據都不一樣，但是為了一致性不得不向它們傳遞相同的數據。
三、 也許大家會發現，使用策略模式后出現很多小類，實際上這也是所有設計模式的“通病”。
現實中的策略模式
大家對于PetShop這個應用肯定很熟悉，在PetShop 4.0里面就使用了策略設計模式：在Petshop4的BLL項目中有一個OrderAsynchronous類和一個OrderSynchronous類，它們都繼承自IorderStrategy。OrderSynchronous以一種同步的方式處理訂單，而OrderAsynchronous先將訂單放在隊列里，然后再對隊列里的訂單進行處理，以一種異步方式。而在BLL中的Order類里通過反射從配置文件讀取策略配置的信息以決定到底是使用哪種訂單處理方式。這里就不貼代碼了，有興趣的可以去下載PetShop看看，主要關注這幾個：PetShop.BLL.Order(如何使用策略以及如何根據配置文件實例化具體的策略)、PetShop.IBLLStrategy. IorderStrategy(策略的接口)、PetShop.BLL. OrderSynchronous、PetShop.BLL. OrderAsynchronous。
總結
在本篇我們從模板方法談起，聊了一些模板方法隨著項目的發展可能造成的問題，但這并不是模板方法的弊端，模板方法關注的是算法骨架的復用，如果你發覺新的問題出現，這可能就是模板方法不再適用的信號。通過我們對項目的擴展，發現繼承在某些時候并不是都能達到代碼復用的目的，這個時候我們應該考慮組合了，而且繼承是一種靜態的編譯期的行為（針對像C#這種強類型靜態語言而言），代碼一經寫定我們就沒有選擇的余地了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/