故事線
開業之后，廣軍一波強有力的宣傳加上學校黃金地段，廣軍的生意例外火爆，他的手幾乎就沒停下來過，
但是吧，忙則生亂吶，有時候他會忘記在漢堡中加生菜，有時候會忘了給奶茶加珍珠，有時候又會給香腸刷了兩次甜辣醬···
諸如此類的問題，讓廣軍很是困擾，
為什么不找一個幫手呢？首先，短時間內找到一個操作技術嫻熟的人本來就不簡單，加上是開業酬賓，本就賺不到多少，主要是口碑要搭建起來，所以萬萬錯不得！！！
怎么辦？廣軍有點犯難，這時候，他的好朋友，也就是我，聽說他又盤了家店，就想著來給他捧場，正好，廣軍給我加了兩份肉，但是我想啊：我靠，果然是好兄弟啊！！
結果中午休息的時候，說起這件事兒，他表示完全不知情，并跟我說起這件事兒，
我就隨口一提：干脆整個流水線玩兒玩兒唄，搞一套，
說者無意，聽者有心，誰知道他還真的去布置了一套，嘖嘖嘖，這還沒賺多少，又破費了，
這套流水線是什么樣的呢？
大概這樣：
做漢堡的流水線：烤肉、烤面包、放生菜、抹奶油、面包夾肉，
要做雞腿堡，就放雞腿肉；要做牛肉堡，就放牛肉···
做奶茶的流水線：取杯（大中小）、放茶、加奶、放料1、放料2、放料3，
如果料不足三種，流程還是要走的，料的上限就三種，要改得改模板了，
烤香腸的流水線就不寫啦，再寫就沒意思了，
就這樣，廣軍開始了忙碌且有序的作業，事實證明，這一舉措將會對他這家店的日后發展起到了舉足輕重的作用，
模板方法模式
現在來看我們這個小故事中要學習的設計模式，模板方法模式，
那么什么是模板方法模式呢？
定義一個操作中的演算法的框架，而將一些步驟延遲到子類中，使得子類可以不改變一個演算法的結構即可重定義該演算法的某些特定步驟，
這么說可能不是很明白，
封裝不變部分，拓展可變部分（把認為是不變部分的演算法封裝到父類實作，而可變部分可以通過繼承來繼續拓展，如果要在來個新產品，蝦堡，知道怎么做吧）
提取公共部分代碼，便于維護，想想看，那個run要是放到子類，那要修改會有幾倍作業量？
行為由父類控制，子類實作，
放到上面的栗子中呢，就是把什么時候要干什么事先定下，比方說先烤肉，再烤面包，至于烤什么肉，烤什么面包，是雞腿、燕麥面包，還是牛肉、切片面包，那就由具體操作人（廣軍）來唯一確定了，
這樣，一切是那么的井然有序！！！
簡單來個漢堡流水的實作流程吧：
類圖展示
實體代碼演示：
#include<iostream>
using namespace std;
class abstracthumber {
public:
virtual void bread() = 0;
virtual void barbecue() = 0;
virtual void cream() = 0;
virtual void lettuce() = 0;
void run() //將共同的核心演算法流程提煉到抽象類
{
this->bread();
this->barbecue();
this->cream();
this->lettuce();
}
};
//將細節延遲到子類
//這兩步便是模板方法模式的精髓
class chicken :public abstracthumber {
public:
void bread() { cout << "雞腿堡的面包" << endl; }
void barbecue() { cout << "雞腿堡的雞腿" << endl; }
void cream() { cout << "雞腿堡的奶油" << endl; }
void lettuce() { cout << "雞腿堡的生菜" << endl; }
};
class beef :public abstracthumber {
public:
void bread() { cout << "牛肉堡的面包" << endl; }
void barbecue() { cout << "牛肉堡的雞腿" << endl; }
void cream() { cout << "牛肉堡的奶油" << endl; }
void lettuce() { cout << "牛肉堡的生菜" << endl; }
};
int main()
{
abstracthumber* a = new chicken();
abstracthumber* b = new beef();
a->run();
b->run();
}
我的想法：
這方法挺好，將核心演算法和細節實作解耦合，不過也是那個拓展的問題還是會存在，
在團隊協作與代碼傳承的應用中也會有不俗的表現吧，
今天就到這里吧，廣軍創業的故事還在寫，大家可以跟著我哦
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/91279.html
標籤：python