开业之后,广军一波强有力的宣传加上学校黄金地段,广军的生意异常火爆,他的手几乎就没停下来过。
但是吧,忙则生乱呐,有时候他会忘记在汉堡中加生菜,有时候会忘了给奶茶加珍珠,有时候又会给香肠刷了两次甜辣酱··· 诸如此类的问题,让广军很是困扰。
为什么不找一个帮手呢?首先,短时间内找到一个操作技术娴熟的人本来就不简单,加上是开业酬宾,本就赚不到多少,主要是口碑要搭建起来,所以万万错不得!!!
怎么办?广军有点犯难。这时候,他的好朋友,也就是我,听说他又盘了家店,就想着来给他捧场,正好,广军给我加了两份肉。但是我想啊:我靠,果然是好兄弟啊!! 结果中午休息的时候,说起这件事儿,他表示完全不知情,并跟我说起这件事儿。
我就随口一提:干脆整个流水线玩儿玩儿呗,搞一套。
说者无意,听者有心。谁知道他还真的去布置了一套,啧啧啧,这还没赚多少,又破费了。
这套流水线是什么样的呢?
大概这样: 做汉堡的流水线:烤肉、烤面包、放生菜、抹奶油、面包夹肉。 要做鸡腿堡,就放鸡腿肉;要做牛肉堡,就放牛肉···
做奶茶的流水线:取杯(大中小)、放茶、加奶、放料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();
}
这方法挺好,将核心算法和细节实现解耦合,不过也是那个拓展的问题还是会存在。 在团队协作与代码传承的应用中也会有不俗的表现吧。