设计模式 ｜ 建造者模式

不是夫子
163 阅读6分钟

概述

Separate the construction of a complex object from its representation so that the same construction process can create different representations.

建造者模式（Builder Pattern）将一个复杂对象的构建过程与它的表示分离，使得同样的构建过程可以创建不同的表示，属于创建型设计模式。

  • 分离了部件的构造(由Builder来负责)和装配(由Director负责)。 从而可以构造出复杂的对象。这个模式适用于：某个对象的构建过程复杂的情况。
  • 由于实现了构建和装配的解耦。不同的构建器，相同的装配，也可以做出不同的对象；相同的构建器，不同的装配顺序也可以做出不同的对象。也就是实现了构建算法、装配算法的解耦，实现了更好的复用。
  • 建造者模式可以将部件和其组装过程分开，一步一步创建一个复杂的对象。用户只需要指定复杂对象的类型就可以得到该对象，而无须知道其内部的具体构造细节。

结构

UML

建造者模式主要包含4个角色：

  1. 产品（Product）：要创建的产品类对象。
  2. 抽象建造者（IBuilder）：建造者的抽象类，规范产品对象的各个组成部分的创建，一般由子类实现具体的创建过程。
  3. 建造者（Concrete Builder）：具体的Builder类，根据不同的业务逻辑，具体化对象的各个组成部分的创建。
  4. 调用者（Director）：调用具体的建造者，来创建对象的各个部分，在指导者中不涉及具体产品的信息，只负责保证对象各部分完整创建或者按某种顺序创建。

实例

// 产品类
type Message struct {
	Body   []byte
	Format string
}

// 抽象建造者
type MessageBuilder interface {
	SetRecipient(recipient string)
	SetText(text string)
	Message() (*Message, error)
}

// JSON 建造者
type JSONMessageBuilder struct {
	messageRecipient string
	messageText      string
}

func (b *JSONMessageBuilder) SetRecipient(recipient string) {
	b.messageRecipient = recipient
}

func (b *JSONMessageBuilder) SetText(text string) {
	b.messageText = text
}

func (b *JSONMessageBuilder) Message() (*Message, error) {
	m := make(map[string]string)
	m["recipient"] = b.messageRecipient
	m["message"] = b.messageText

	data, err := json.Marshal(m)
	if err != nil {
		return nil, err
	}

	return &Message{Body: data, Format: "JSON"}, nil
}

// XML 建造者
type XMLMessageBuilder struct {
	messageRecipient string
	messageText      string
}

func (b *XMLMessageBuilder) SetRecipient(recipient string) {
	b.messageRecipient = recipient
}

func (b *XMLMessageBuilder) SetText(text string) {
	b.messageText = text
}

func (b *XMLMessageBuilder) Message() (*Message, error) {
	type XMLMessage struct {
		Recipient string `xml:"recipient"`
		Text      string `xml:"body"`
	}

	m := XMLMessage{
		Recipient: b.messageRecipient,
		Text:      b.messageText,
	}

	data, err := xml.Marshal(m)
	if err != nil {
		return nil, err
	}

	return &Message{Body: data, Format: "XML"}, nil
}

// 指挥者
type Sender struct{}

func (s *Sender) BuildMessage(builder MessageBuilder) (*Message, error) {
	builder.SetRecipient("Tom")
	builder.SetText("Hello, world!")
	return builder.Message()
}

func main() {
	sender := &Sender{}

	jsonMsg, err := sender.BuildMessage(&JSONMessageBuilder{})
	if err != nil {
		panic(err)
	}
	fmt.Printf("json message: %s\n", string(jsonMsg.Body))

	xmlMsg, err := sender.BuildMessage(&XMLMessageBuilder{})
	if err != nil {
		panic(err)
	}
	fmt.Printf("xml message: %s\n", string(xmlMsg.Body))
}

场景

建造者（Builder）模式创建的是复杂对象，其产品的各个部分经常面临着剧烈的变化，但将它们组合在一起的算法却相对稳定，所以它通常在以下场合使用。

  • 创建的对象较复杂，由多个部件构成，各部件面临着复杂的变化，但构件间的建造顺序是稳定的。
  • 创建复杂对象的算法独立于该对象的组成部分以及它们的装配方式，即产品的构建过程和最终的表示是独立的。

案例

如果构造函数的参数过多，会导致参数列表变得很长，代码可读性和易用性都会变差，这时可以使用建造者模式。

const (
	DEFAULT_MAX_TOTAL = 10
	DEFAULT_MAX_IDLE  = 8
	DEFAULT_MIN_IDLE  = 2
)

// 产品类
type ResourcePoolConfig struct {
	name     string
	maxTotal int
	maxIdle  int
	minIdle  int
}

func (r *ResourcePoolConfig) Info() string {
	return fmt.Sprintf("name: %s\nmaxTotal: %d\nmaxIdle: %d\nminIdle: %d",
		r.name, r.maxTotal, r.maxIdle, r.minIdle)
}

// 抽象建造者
type IBuilder interface {
	SetMaxTotal(maxTotal int) IBuilder
	SetMaxIdle(maxIdle int) IBuilder
	SetMinIdle(minIdle int) IBuilder
	Build() *ResourcePoolConfig
}

// 建造者
type ResourcePoolConfigBuilder struct {
	builder *ResourcePoolConfig
}

func NewResourcePoolConfigBuilder(name string) *ResourcePoolConfigBuilder {
	return &ResourcePoolConfigBuilder{builder: &ResourcePoolConfig{name: name}}
}

func (b *ResourcePoolConfigBuilder) SetMaxTotal(maxTotal int) IBuilder {
	if maxTotal <= 0 {
		panic("maxTotal is less than or equal to zero")
	}
	b.builder.maxTotal = maxTotal
	return b
}

func (b *ResourcePoolConfigBuilder) SetMaxIdle(maxIdle int) IBuilder {
	if maxIdle < 0 {
		panic("maxIdle is less than zero")
	}
	b.builder.maxIdle = maxIdle
	return b
}

func (b *ResourcePoolConfigBuilder) SetMinIdle(minIdle int) IBuilder {
	if minIdle < 0 {
		panic("minIdle is less than zero")
	}
	b.builder.minIdle = minIdle
	return b
}

func (b *ResourcePoolConfigBuilder) Build() *ResourcePoolConfig {
	if len(b.builder.name) == 0 {
		panic("invalid name")
	}
	if b.builder.maxTotal == 0 {
		b.builder.maxTotal = DEFAULT_MAX_TOTAL
	}
	if b.builder.maxIdle == 0 {
		b.builder.maxIdle = DEFAULT_MAX_IDLE
	}
	if b.builder.minIdle == 0 {
		b.builder.minIdle = DEFAULT_MIN_IDLE
	}
	if b.builder.maxIdle > b.builder.maxTotal {
		panic("maxIdle is more than maxTotal")
	}
	if b.builder.minIdle > b.builder.maxTotal || b.builder.minIdle > b.builder.maxIdle {
		panic("minIdle is more than maxTotal or minIdle is more than maxIdle")
	}

	return &ResourcePoolConfig{
		name:     b.builder.name,
		maxTotal: b.builder.maxTotal,
		maxIdle:  b.builder.maxIdle,
		minIdle:  b.builder.minIdle,
	}
}

func main() {
	info := NewResourcePoolConfigBuilder("dbconnectionpool").
		SetMaxTotal(15).
		SetMaxIdle(10).
		SetMinIdle(5).
		Build().
		Info()
	fmt.Println(info)
}

总结

优缺点

优点

  • 建造者模式的封装性很好。使用建造者模式可以有效的封装变化，在使用建造者模式的场景中，一般产品类和建造者类是比较稳定的，因此，将主要的业务逻辑封装在指挥者类中对整体而言可以取得比较好的稳定性。
  • 在建造者模式中，客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象。
  • 可以更加精细地控制产品的创建过程 。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程。
  • 建造者模式很容易进行扩展。如果有新的需求，通过实现一个新的建造者类就可以完成，基本上不用修改之前已经测试通过的代码，因此也就不会对原有功能引入风险。符合开闭原则。

缺点

  • 造者模式所创建的产品一般具有较多的共同点，其组成部分相似，如果产品之间的差异性很大，则不适合使用建造者模式，因此其使用范围受到一定的限制。

与工厂模式对比

工厂方法模式 VS 建造者模式

工厂方法模式注重的是整体对象的创建方式；而建造者模式注重的是部件构建的过程，意在通过一步一步地精确构造创建出一个复杂的对象。 我们举个简单例子来说明两者的差异，如要制造一个超人，如果使用工厂方法模式，直接产生出来的就是一个力大无穷、能够飞翔、内裤外穿的超人；而如果使用建造者模式，则需要组装手、头、脚、躯干等部分，然后再把内裤外穿，于是一个超人就诞生了。

抽象工厂模式 VS 建造者模式

抽象工厂模式实现对产品家族的创建，一个产品家族是这样的一系列产品：具有不同分类维度的产品组合，采用抽象工厂模式则是不需要关心构建过程，只关心什么产品由什么工厂生产即可。 建造者模式则是要求按照指定的蓝图建造产品，它的主要目的是通过组装零配件而产生一个新产品。 如果将抽象工厂模式看成汽车配件生产工厂，生产一个产品族的产品，那么建造者模式就是一个汽车组装工厂，通过对部件的组装可以返回一辆完整的汽车。

我正在参与掘金技术社区创作者签约计划招募活动，点击链接报名投稿。

avatar
文章
阅读
粉丝