我使用過一個簡單的后臺服務框架.這個框架上手很容易,我只需要繼承一個基類,同時實現(xiàn),或重寫(override)基類聲明的幾個接口(這些接口聲明為虛函數(shù),或者純虛函數(shù)),然后調用基類定義好的run()函數(shù),便可以將框架代碼運行起來.run函數(shù)做的事情,是依序調用上述的幾個接口:

class Service { public : int run(){// ....step1(); // 收包 , 解包step2(); // 業(yè)務邏輯處理step3(); // 回包step4(); //資源釋放//.... } protected: virtual int step1(){ // 收包,解包邏輯實現(xiàn) //...} virtual int step3(){ // 回包邏輯實現(xiàn) //... } virtual int step4(){ //資源釋放 //... } virtual int step2() =0 ; //純虛函數(shù),派生類實現(xiàn) }

其中收包,解包,回包,釋放資源等動作,框架會提供一份實現(xiàn),由于我們有時候會采用其他的數(shù)據(jù)協(xié)議,所以基類也將收包回包等函數(shù)聲明為虛函數(shù),允許我們針對新的協(xié)議進行函數(shù)的重寫(override).而對于業(yè)務邏輯處理函數(shù),也就是step2,框架無法為我們實現(xiàn),我們需要根據(jù)具體的業(yè)務需求來實現(xiàn)該函數(shù),在派生類中來實現(xiàn)step2函數(shù):

class MyService : public Service{ int step2(){ // 具體業(yè)務邏輯的實現(xiàn) } }

派生類實現(xiàn)了step2函數(shù)后,通過調用run函數(shù)來運行程序:

void main (){ //...準備工作 Service * myService = new MyService(); if( myService->run()){//...后續(xù)處理 } // ... }

我們的后臺服務框架例子中,run函數(shù)定義了一個服務的穩(wěn)定執(zhí)行步驟,但某個步驟有著特定的需求無法馬上定義,需要延遲到派生類中去實現(xiàn),這時候就需要采用模板方法模式.模板方法模式要解決的問題是:如何在確定穩(wěn)定操作結構的前提下,靈活地應對各個子步驟的變化或者晚期實現(xiàn)需求?

李建忠老師曾提過,重構獲得設計模式(Refactoring to Patterns).設計模式的應用不宜先入為主,一上來就使用設計模式是對設計模式的最大誤用,在敏捷軟件開發(fā)中,提倡使用的是通過重構來獲得設計模式,這也是最好的使用設計模式的方法.

而關于重構的關鍵技法,包括了:

• 靜態(tài)->動態(tài)
• 早綁定->晚綁定
• 繼承->組合
• 編譯時依賴->運行時依賴
• 緊耦合->松耦合

接下來我們來看看如何將一個程序,重構成模板方法模式.現(xiàn)代軟件專業(yè)分工之后,也出現(xiàn)了"框架與應用程序的劃分",框架實現(xiàn)人員先定義好框架的執(zhí)行流程,也就是算法骨架(穩(wěn)定),并提供可重寫(overide)的接口(變化)給應用開發(fā)人員,以開發(fā)適應其應用程序的子步驟.模板方法通過晚綁定,實現(xiàn)了框架與應用程序之間的松耦合.

現(xiàn)在我們需要實現(xiàn)一個程序庫,需要四個步驟來完成相應功能.其中step1,step3步驟穩(wěn)定,而step2,step4則根據(jù)不同應用的具體需要,自行定義其具體功能,庫開發(fā)人員無法預先實現(xiàn)好step2,step4.那么庫開發(fā)人員可以先寫好：

// 庫開發(fā)人員 class Library{public:void step1(){// 步驟1的具體實現(xiàn)//...}void step3(){//步驟3的具體實現(xiàn)//...}

應用程序開發(fā)人員則根據(jù)具體的應用需求，來實現(xiàn)剩余的兩個步驟：

//應用程序開發(fā)人員 class Application{ public:void step2(){//步驟2的具體實現(xiàn)//...}bool step4(){//步驟4的具體實現(xiàn)//...} }

然后應用程序開發(fā)人員還需要寫一個main方法,將步驟以某種流程串起來:

//穩(wěn)定public static void main(String args[]) {Library lib = new Library();Application app = new Application();lib.step1();if (app.step2()) {lib.step3();}app.step4();}

這種辦法實際上是一種C語言結構化的實現(xiàn)方式,雖然用的是C++,但沒有體現(xiàn)出面向對象的特性來.main方法中,四個步驟的調用過程是相對穩(wěn)定的,我們可以把這種穩(wěn)定提升到庫的實現(xiàn)中去,而應用程序開發(fā)人員,只需要實現(xiàn)"變化"的代碼即可.這就引出了第二種做法.

第二種做法,是庫開發(fā)人員不僅實現(xiàn)step1(),step3(),同時將step2(),step4()聲明為純虛函數(shù),等待應用程序開發(fā)人員自己去實現(xiàn)這兩個純虛函數(shù).注意到,main方法中定義的執(zhí)行流程是相對穩(wěn)定的,完全可以把這些步驟移動到庫類中去.

//庫開發(fā)人員 class Library{public :void run (){step1(); if(step2()){ //支持變化-->虛函數(shù)的多態(tài)調用step3();}step4(); //支持變化-->虛函數(shù)的多態(tài)調用} protected:void step1(){ //穩(wěn)定//... }void step3(){ //穩(wěn)定//...}virtual bool step2() =0; //純虛函數(shù)virtual void step4() = 0; //純虛函數(shù) virtual ~Library(){//...} };

注意step2,step4為純虛函數(shù),這是因為庫開發(fā)人員無法知道怎么寫,留給程序庫開發(fā)人員來實現(xiàn),也就是"把實現(xiàn)延遲",這在C++中體現(xiàn)為虛函數(shù)或純虛函數(shù),由應用程序開發(fā)人員繼承Library以實現(xiàn)兩個純虛函數(shù).這一段代碼實際上體現(xiàn)了大部分設計模式應用的特點,也就是在穩(wěn)定中包含著變化,run函數(shù)的算法流程是穩(wěn)定的,但是算法的某個步驟是可變的,可變的延遲實現(xiàn):

class Application: public Library{ protected:virtual bool step2(){//...子類重寫實現(xiàn)}virtual void step4(){//...子類重寫實現(xiàn)} };

然后,應用程序開發(fā)人員,只需要通過多態(tài)指針來完成框架的使用:

public static void main(String args[]) {Library * ptr = new Application();ptr->run();delete ptr; }

指針ptr是一個多態(tài)指針,它聲明為Library類型,實際指向的對象為Application類型對象.它會調用到基類的run方法,遇到step2,step4函數(shù)時,通過虛函數(shù)機制,調用到派生類實現(xiàn)的step2,step4函數(shù).

回顧兩種實現(xiàn)方式,我們可以發(fā)現(xiàn),第一種實現(xiàn)方式中:

• 庫開發(fā)者負責step1,step3 ;
  
• 應用程序開發(fā)者負責step2,step4,執(zhí)行流程(穩(wěn)定)

采用了模板方法模式的實現(xiàn)方式中:

• 庫開發(fā)者負責step1,step3,執(zhí)行流程(穩(wěn)定)
• 應用程序開發(fā)者負責step2,step4

一般來說,框架/組件/庫的實現(xiàn),總是要先于應用程序的開發(fā)的.在第一種方式中,應用程序開發(fā)者(晚開發(fā))的執(zhí)行流程調用了庫開發(fā)者定義好的函數(shù)(早開發(fā)),稱為早綁定,而反過來在模板方法模式中,庫開發(fā)者在執(zhí)行流程中先調用了step2,step4函數(shù),而這兩個函數(shù)需要延遲到應用程序開發(fā)人員真正實現(xiàn)時,才通過虛函數(shù)機制進行調用,這種方式則稱為早綁定.這便是重構使用設計模式的技法: 早綁定->晚綁定.

回過頭來看看模板方法模式的定義:定義一個操作中的算法的骨架,而將一些步驟延遲到子類中.Template Method使得子類刻意不改變一個算法的結構即可重定義該算法的某些特定步驟.(<> GoF) 所謂的骨架,要求是相對穩(wěn)定的,在上面的例子中,如果step1,step3也是不穩(wěn)定的,那么該情景下就不適用于適用設計模式,原因是軟件體系中所有的東西都不穩(wěn)定.設計模式的假設條件是必須有一個穩(wěn)定點,如果沒有穩(wěn)定點,那么設計模式?jīng)]有任何作用.反過來說,如果所有的步驟都是穩(wěn)定的,這種極端情況也不適用于適用設計模式.設計模式總是處理"穩(wěn)定中的變化"這種情景.設計模式最大的作用,是在穩(wěn)定與變化之間尋找隔離點,然后來分離它們,從而來管理變化.從而我們也能夠得到啟發(fā),學會分析出軟件體系結構中哪部分是穩(wěn)定的,哪部分是變化的,是學好設計模式的關鍵點.

再來看一看模板方法設計模式的結構:其中TemplateMethod() 方法也就是我們上面所說的run函數(shù),它相對穩(wěn)定,primitiveOperation1(),primitiveOperation2()為兩個變化的函數(shù),可由派生類實現(xiàn),在TemplateMethod()中調用步驟.在下圖中,紅色圈為穩(wěn)定的部分,而黑色圈為變化的部分.

在面向對象的時代,絕大多數(shù)的框架設計都使用了模板方法模式.作為一個應用程序開發(fā)人員,我們往往只需要實現(xiàn)幾個步驟,框架便會把我們的步驟"串接"到執(zhí)行流程中,有時候甚至連main函數(shù)都不用我們去實現(xiàn).這樣子也有弊端,我們看不見框架的執(zhí)行流程,執(zhí)行細節(jié)是怎么樣的,往往有一種"只見樹木不見森林"的感覺.

最后來總結以下模板方法設計模式.Template Method設計模式是一種非?；A性的設計模式,它要解決的問題是如何在確定穩(wěn)定操作結構的前提下,來靈活應對各個子步驟的變化或者晚期實現(xiàn)需求.它使用了函數(shù)的多態(tài)性機制,為應用程序框架提供了靈活的拓展點,是代碼復用方面的基本實現(xiàn)結構.Template Method設計模式明顯劃分了穩(wěn)定與變化的關系,除了靈活應對子步驟的變化外,也是晚綁定的典型應用,通過反向控制結構,使得早期的代碼可以調用晚期代碼.而在具體實現(xiàn)上,被Template Method調用的虛函數(shù),可以具有實現(xiàn),也可以沒有任何實現(xiàn),這在C++中體現(xiàn)為虛函數(shù)或者純虛函數(shù),一般將這些函數(shù)設置為proteced方法.



總結

以上是生活随笔為你收集整理的C++设计模式:Template Method的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。