设计模式——设计模式选择——创建型

这篇博客详细介绍了创建型设计模式,包括抽象工厂、生成器、工厂方法、原型和单例模式。这些模式提供了对象创建的抽象接口,允许在运行时决定创建哪些类的实例,提升了代码的灵活性和可维护性。例如,抽象工厂模式用于创建一系列相关或相互依赖的对象,而原型模式则通过克隆现有对象来创建新的对象。
摘要由CSDN通过智能技术生成

对象创建型模式

Abstract Factory(Kit)——抽象工厂

意图

提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类

动机

用以说明一个设计同题以及如何用模式中的类、对象来解决该问题的特定情景。该情景会帮助你理解随后对模式更抽象的描述。

适用性

  1. 一个系统要独立于它们的产品的创建、组合和表示时
  2. 一个系统要由多个产品系列中的一个来配置时
  3. 当你强调一系列相关的产品对象的设计以便进行联合使用时
  4. 当你提供一个产品类库,而只想显示它们的接口而不是实现时

结构

这里写图片描述

参与者

  • AbstractFactory
    声明一个创建抽象产品对象的操作接口
  • ConcreteFactory
    实现创建具体产品对象的操作
  • AbstractProduct
    为一类产品对象声明一个接口。
  • ConcreteProduct
    定义一个将被相应的具体工厂创建的产品对象
    实现AbstractProduct接口
  • Client
    仅使用由AbstractFactory和AbstractProduct类声明的接口

协作

  • 通常在运行时刻创建一个ConcreteFactroy类的实例。这一具体的工厂创建具有特定实现的产品对象。为创建不同的产品对象,客户应使用不同的具体工厂。
  • AbstractFactory将产品对象的创建延迟到它的ConcreteFactory子类。

效果

AbstractFactory模式有下面的一些优点和缺点:

它分离了具体的类

Abstract Factory模式帮助你控制一个应用创建的对象的类。因为一个工厂封装创建产品对象的责任和过程,它将客户与类的实现分离。客户通过它们的抽象接口操纵实例。产品的类名也在具体工厂的实现中被分离;它们不出现在客户代码中。

它使得易于交换产品系列

一个具体工厂类在一个应用中仅出现一次一一即在它初始化的时候。这使得改变一个应用的具体工厂变得很容易。它只需改变具体的工厂即可使用不同的产品配置,这是因为一个抽象工厂创建了一个完整的产品系列,所以整个产品系列会立刻改变。

它有利于产品的一致性

当一个系列中的产品对象被设计成一起工作时,一个应用一次只能使用同一个系列中的对象,这一点很重要。而Abstract Factory很容易实现这一点。

难以支持新种类的产品

难以扩展抽象工厂以生产新种类的产品。这是因为Abstract Factory接口确定了可以被创建的产品集合。支持新种类的产品就需要扩展该工厂接口,这将涉及Abstract Factory类及其所有子类的改变。我们会在实现一节讨论这个问题的一个解决办法。

实现

下面是实现Abstract Factory模式的一些有用技术:

将工厂作为单件

一个应用中一般每个产品系列只需一个Concrete Factory的实例。因此工厂通常最好实现为一个Singleton。

创建产品

Abstract Factory仅声明一个创建产品的接口,真正创建产品是由Concrete Product子类实现的。最通常的一个办法是为每一个产品定义一个工厂方法(参见Factory Method)。一个具体的工厂将为每个产品重定义该工厂方法以指定产品。虽然这样的实现很简单,但它却要求每个产品系列都要有一个新的具体工厂子类,即使这些产品系列的差别很小。

如果有多个可能的产品系列,具体工厂也可以使用Prototype模式来实现。具体工厂使用产品系列中每一个产品的原型实例来初始化,且它通过复制它的原型来创建新的产品。在基于原型的方法中,使得不是每个新的产品系列都需要一个新的具体工厂类。

定义可扩展的工厂

Abstract Factory通常为每一种它可以生产的产品定义一个操作。产品的种类被编码在操作型构中。增加一种新的产品要求改变Abstract Factory的接口以及所有与它相关的类。一个更灵活但不太安全的设计是给创建对象的操作增加一个参数。该参数指定了将被创建的对象的种类。它可以是一个类标识符、一个整数、一个字符串,或其他任何可以标识这种产品的东西。实际上使用这种方法,Abstract Factory只需要一个”Make”操作和一个指示要创建对象的种类的参数。这是前面已经讨论过的基于Prototype的和基于类的抽象工厂的技术。

相关模式

  • Abstract Factory类通常用工厂方法(Factory Method)实现,但它们也可以用Prototype实现。
  • 一个具体的工厂通常是一个单件(Singleton)。

Builder——生成器

意图

将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示

动机

用以说明一个设计同题以及如何用模式中的类、对象来解决该问题的特定情景。该情景会帮助你理解随后对模式更抽象的描述

适用性

在以下情况使用Builder模式

  • 当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。
  • 当构造过程必须允许被构造的对象有不同的表示时。

结构

这里写图片描述

参与者

  • Builder
    为创建一个product对象的各个部件指定抽象接口。
  • ConcreteBuilder
    实现Builder的接口以构造和装配该产品的各个部件。
    定义并明确它所创建的表示。
    提供一个检索产品的接口(例如,GetResult)。
  • Director
    构造一个使用Builder接口的对象。
  • Product
    表示被构造的复杂对象。ConcreteBuilder创建该产品的内部表示并定义它的装配过程。
    包含定义组成部件的类,包括将这些部件装配成最终产品的接口。

协作

  • 客户创建Director对象,并用它所想要的Builder对象进行配置。
  • 一旦产品部件被生成,导向器就会通知生成器。
  • 生成器处理导向器的请求,并将部件添加到该产品中。
  • 客户从生成器中检索产品。

下面的交互图说明了Builder和Director是如何与一个客户协作的。
这里写图片描述

效果

它使你可以改变一个产品的内部表示

Builder对象提供给导向器一个构造产品的抽象接口。该接口使得生成器可以隐藏这个产品的表示和内部结构。它同时也隐藏了该产品是如何装配的。因为产

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Mr___Ray

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值