C 實現設計模式 4 模板方法模式

*參考書籍* :

公司接到乙個xx模型公司的的訂單 , 需要生產10萬悍馬的車模 , 只做基本的實現 , 不靠慮擴充套件性 . 那麼就開始埋頭幹 .

先按照最一般的經驗設計類圖 , 如圖所示 :

非常簡單的實現 , 悍馬車有兩個型號 , h1和h2 . 按照需求 , 只需要悍馬模型 , 那就給你悍馬模型 .先寫乙個抽象類 , 然後兩個不同型號的模型實現類 , 通過簡單的繼承就可以實現業務要求. 我們先從抽象類開始編寫 .

//抽象悍馬模型
class hummermodel
//能發動 , 還要能停下來 , 那才是真本事
virtual void
stop()
//按喇叭會出聲音 , 是滴滴叫 , 還是嗶嗶叫
virtual void
alarm()
//引擎會轟隆隆地響 , 不響那是假的
virtual void
engineboom()
//那模型應該會跑吧 , 別管是人推的 , 還是電力驅動的 , 總之會跑
virtual void
run(
)

在抽象類中 , 我們定義了悍馬模型都必須具有的特質 : 能夠發動 , 停止 , 喇叭迴響 , 引擎可以轟鳴.但是每個型號的悍馬實現是不同的. h1型號的悍馬如下 :

//h1型號悍馬模型
class hummerh1model : public hummermodel
void
stop()
void
alarm()
void
engineboom()
public:
void
run()}
;

注意看 , run()方法, 這是乙個彙總的方法, 乙個模型生產成功了 , 總要拿給客戶檢測的 , 怎麼檢測 ,讓它跑起來 .通過run()方法 , 把模型的所有功能都測試到了 .h2型悍馬的** , 如下 :

//h2型號悍馬模型
class hummerh2model : public hummermodel
void
stop()
void
alarm()
void
engineboom()
public:
void
run()}
;

好了 , 程式編寫到這裡 ,已經發現問題了 , 兩個實現類的run()方法都是完全相同的,那這個run()方法的實現應該出現在抽象類 , 不應該出現在實現類上,抽象是所有子類的共性封裝.

注意 : 在軟體開發當中 , 如果相同的一段**複製過兩次 , 就需要對設計產生懷疑 , 架構師要明確地說明為什麼相同的邏輯要出現兩次或更多次 .

修改之後的類圖 :

定義 :定義乙個操作中演算法的框架，而將一些步驟延遲到子類中 . 使得子類可以不改變演算法的結構即可重定義該演算法中的某些特定步驟 .

uml類圖 :

**如下 :

//模板方法模式
#if 0
//抽象悍馬模型
class hummermodel
//能發動 , 還要能停下來 , 那才是真本事
virtual void
stop()
//按喇叭會出聲音 , 是滴滴叫 , 還是嗶嗶叫
virtual void
alarm()
//引擎會轟隆隆地響 , 不響那是假的
virtual void
engineboom()
public:
void
run()}
;//h1型號悍馬模型
class hummerh1model : public hummermodel
void
stop()
void
alarm()
void
engineboom()
};//h2型號悍馬模型
class hummerh2model : public hummermodel
void
stop()
void
alarm()
void
engineboom()
};intmain()
#endif

執行結果 :

模版方法模式的結構

抽象類的任務是搭建邏輯的框架，通常由經驗豐富的人員編寫，因為抽象類的好壞直接決定了程式是否穩定性 .

模板方法模式的優點

模板方法模式的缺點

按照我們的設計習慣，抽象類負責宣告最抽象、最一般的事物屬性和方法，實現類完成具體的事物屬性和方法. 但是模板方法模式卻顛倒了，抽象類定義了部分抽象方法，由子類實現，子類執行的結果影響了父類的結果，也就是子類對父類產生了影響，這在複雜的專案中，會帶來**閱讀的難度，而且也會讓新手產生不適感 .

模板方法模式的使用場景《設計模式之禪第二版》

《設計模式》

C 實現設計模式 4 模板方法模式

C 設計模式（4）模板方法模式

設計模式模板方法模式C 實現

設計模式（4）模板方法模式

C 實現 設計模式 4 模板方法模式

C 設計模式（4） 模板方法模式

設計模式 模板方法模式C 實現

設計模式（4） 模板方法模式

相關推薦

C 實現設計模式 4 模板方法模式

C 設計模式（4）模板方法模式

設計模式模板方法模式C 實現

設計模式（4）模板方法模式