[翻译]生成器模式

意图

  • 将复杂对象的实例创建过程与表现形式分离,这样同一个创建过程可以创建不同的表现形式;
  • 将复杂的表现形式进行分解,这样同一个对象展现过程可以创建不同的表现形式。

问题

    应用程序中如果需要创建复杂集合体的各个元素,应把复杂集合体的内容放在程序内部,而将展示复杂集合体的代码放在程序的窗口级别。

讨论

    将解析对象实例的持久化内容(比如RTF文件)的算法与创建和表示对象实例(比如ASCII、TeX、文本组件)的算法分离。本模式的侧重点是创建复杂的聚合体对象。

    当需要解析外部格式时,调用者调用生成器服务,每次生成器服务被调用,生成器服务都会创建复杂对象实例的一部分,并且在生成器内部保持对象实例的状态,直到复杂对象实例创建完毕。调用结束后,客户端可以从生成器服务中获取完整的对象实例。

    生成器模式对对象实例创建过程有较好的控制。其它创建型模式一次就可以将对象实例创建成功,而生成器模式可以在调用者的控制下一步一步的创建对象实例。

结构 

    如下图所示,Reader类封装了解析公共输入内容的过程。而生成器层(Converter类)根据需要将输入内容转换为不同的表示形式或者对象实例。

 

示例

    生成器模式将复杂对象的创建过程与表现形式分离,这样同一个创建过程可以创建不同的表现形式。该模式可用于在快餐店制作儿童套餐。儿童套餐通常包括主食、零食、饮料和玩具,例如一个汉堡包、炸薯条、一杯可乐和玩具恐龙。需要注意的是,虽然儿童套餐可以有很多种组合,比如顾客点的主食可以是汉堡包、三明治或者炸鸡,但是制作儿童套餐的过程是相同的。快餐店员工负责将主食、零食和玩具打包在一起,饮料则另外装在单独的杯子中。其它的快餐店也是采用的相同的制作过程。

 

 

核对列表

1、确认要解决的问题是否存在公共的输入,并且根据输入内容生成不同的表现形式或者输出;

2、在类Reader中封装对公共输入内容的解析操作;

3、为所有可能的表示形式设计一个公共的创建方案,在生成器接口中获取这个方案的所有步骤;

4、为每一种表示形式定义一个生成器子类,继承生成器接口;

5、客户端创建一个Reader类实例和一个生成器实例,并在Read类实例中保存生成器实例引用;

6、客户端调用Reader类实例创建表现形式;

7、客户端调用生成器实例获取创建成功的表现形式。

经验

1)有时创建型模式互为补充:生成器模式可以使用其它创建型模式实现对象实例的一步步创建。实现抽象工厂模式、生成器模式和原型模式时可以采用单件模式;

2)生成器模式侧重于逐步生成复杂的对象实例,而抽象工厂模式注重创建一组对象实例(不论是简单对象还是复杂对象)。生成器模式视返回对象实例为对象实例创建过程的最后一步,而抽象工厂模式会立即返回创建的对象实例。

3)生成器模式创建的对象实例通常为复杂对象(混合物);

4)软件设计之初,常采用工厂模式(该模式实现简单,定制性强,可通过创建新子类以生成新对象)。随着设计的深入,设计人员认为程序应该设计的更加灵活时,就会采用抽象工厂模式、原型模式或者生成器模式(这些模式更灵活,代码实现也更复杂)。

 

原文地址:http://sourcemaking.com/design_patterns/builder

下面的链接是我写的一个实例程序:

http://pan.baidu.com/s/1dDpJwjR

<think>好的,用户问的是生成器模式有哪些叫法。首先,我需要确认生成器模式的其他名称。记得设计模式中的生成器模式,可能还有其他翻译或者别名。比如,英文是Builder Pattern,所以直译的话可能有建造者模式、构建器模式这些叫法。 接下来,我需要回忆一下不同的资料或书籍中是否用过不同的术语。比如《设计模式:可复用面向对象软件的基础》这本书里,可能用的是生成器模式或者建造者模式。另外,有些地方可能会用构造者模式,但不太常见。需要确认一下这些译名的准确性。 另外,有些资料中可能会根据用途来命名,比如分步构建器,但这不是正式的名称,而是描述性的说法。需要区分正式别名和非正式的说法。可能还有生成者模式,不过可能不太准确。 还需要考虑用户可能的背景。如果是中文资料,建造者模式这个翻译比较常见,尤其是在一些经典的书籍或文章中。而生成器模式可能在一些较新的文献或者不同的翻译版本中出现。也有可能用户接触的是不同的翻译版本,所以需要列举所有可能的名称。 再检查一下是否有其他可能的变体,比如生成器、建造者、构建器,这些词在中文里都可能用来翻译Builder。所以对应的模式名称可能是生成器模式、建造者模式、构建器模式。构造器模式可能容易和构造函数混淆,所以可能不太常见,但有时候也会被提到。 总结下来,常见的别名包括建造者模式、构建器模式,可能还有生成者模式,不过最后一个可能较少使用。需要确保这些名称的正确性,避免误导用户。另外,应该提到这些不同的叫法都是指同一个设计模式,即Builder Pattern,只是翻译或习惯用法的不同。</think>生成器模式在不同资料或技术场景中主要有以下几种常见叫法: 1. **建造者模式** 这是最广泛使用的中文译名,尤其在经典设计模式书籍和框架源码中常见,强调"分步骤构建复杂对象"的特性。 2. **构建器模式** 强调模式中用于创建对象的"Builder"组件,常见于技术文档和API设计中,如Java的StringBuilder类。 3. **生成器模式** 直译自英文"Builder Pattern",突出对象生成过程的可控性,在UML图例和模式讲解中使用较多。 4. **构造者模式**(较少用) 偶见于早期翻译资料,需注意与构造函数(Constructor)概念区分。 5. **分步构建模式**(描述性说法) 非正式名称,用于解释模式工作原理,强调分步骤构建对象的特性。 所有名称均指代同一种设计模式,区别仅在于翻译习惯或上下文侧重。推荐优先使用「建造者模式」或「构建器模式」以确保交流准确性,这两个术语在《设计模式》经典著作(GoF书籍)和技术社区中被广泛认可。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值