前两篇文章我已经养了一堆宠物,这么多宠物我放在家里也不是个办法,便想着能不能整个牧场,把我这些宠物放进去养,让他们产生点经济价值。于是我把我现在有的所有动物叫到一块,一看是这些:
这时候有我一个来自理塘的朋友到我这,他也想给他的动物朋友们整个牧场。但是人家是真的动物朋友,我这全是赛博动物朋友,人家要的是真牧场,我这是QQ牧场。这导致最终要交付的东西不一样,分别为QQPasture和RealPasture:
显然,除了QQPasture是得注册账号创建、RealPasture是得真正雇人搭建外,里面放的动物都是上面有的那些动物。也就是说,这两个牧场的内容(参数属性)是相同的,但是具体要实现的效果(类方法)不同。这种情形正适合生成器模式(Builder Pattern)。
于是我们抽象出一个工人接口Builder用于建造农场,派生出两个子类,分别用于创建QQ牧场和真实牧场。当然,这两个子类在覆写Builder中的setter外,也要根据实际所建造的产品的性质拥有自己单独的方法,QQ牧场建造者的个性方法即是根据获取的数据去注册账号,而真实牧场建造者个性方法则是选块地皮建房子。
而谁来决定具体牧场里面要养什么动物呢?这时我们就需要一个包工头来告诉Builder们牧场里面应该放哪几种动物。我将我的些动物朋友分成三类:畜类(牛、羊)、禽类(鸡、鸭)、宠物类(猫、狗),从而给出三种牧场规划:畜类牧场、禽类牧场、宠物牧场,然后把规划给对应的Builder来建造:
P.S.
Director和Builder的工作顺序可形象的表达成下面这样:
首先Director制定出产品的形式,并具体的说明每种产品类中的每个属性值,然后让BuilderX依赖Director的具体构建方法获得这份“属性清单”。
然后BuilderX将这份“属性清单”上的属性值“记忆”到自己的变量表中,然后通过从Builder那继承来的构建方法与自己个性化的构建函数构建出自家该制作的目标产品,把产品给客户端。