为你自己学Go
  • README
  • PART01.Web框架概览
    • 1.01 Web框架概览:学习路线
    • 1.02 Web框架概览-Beego框架分析
    • 1.03 Web框架概览-GIN框架分析
    • 1.04 Web框架概览-Iris框架分析
    • 1.05 Web框架概览-Echo框架分析
  • PART02.Server
    • 2.01 Server详解与面试要点
  • PART03.路由树
    • 3.01 路由树-Beego&GIN&Echo实现与设计总结
    • 3.02 路由树-全静态匹配
    • 3.03 路由树-TDD起步
    • 3.04 路由树-静态匹配测试用例
    • 3.05 路由树-静态匹配之路由查找
    • 3.06 路由树-静态匹配之集成Server
    • 3.07 路由树-通配符匹配之路由注册
    • 3.08 路由树-通配符匹配之路由查找与测试
    • 3.09 路由树-参数路径之基本注册和查找
    • 3.10 路由树-参数路径之校验
    • 3.11 路由树-参数路径之参数值
    • 3.12 路由树-总结与面试要点
  • PART04.课后复习
    • 4.01 课后复习-Server
    • 4.02 课后复习-Route
  • PART05.Context
    • 5.01 Context-简介
    • 5.02 Context-Beego Context设计分析
    • 5.03 Context-Gin Context设计分析
    • 5.04 Context-Echo和Iris的Context设计分析
    • 5.05 Context-处理输入输出总结
    • 5.06 Context-处理输入之Body输入
    • 5.07 Context-处理输入之表单输入
    • 5.08 Context-处理输入之查询参数、路径参数和StringValue
    • 5.09 Context-处理输出
    • 5.10 Context-总结与面试要点
  • PART06.AOP
    • 6.01 AOP简介与不同框架设计概览
    • 6.02 AOP设计方案-Middleware
  • PART07.Middleware
    • 7.01 Middleware-AccessLog
    • 7.02 Middleware-Trace简介和OpenTelemetry
    • 7.03 Middleware-OpenTelemetry测试
    • 7.04 Middleware-OpenTelemetry总结
    • 7.05 Prometheus详解
    • 7.06 Middleware-Prometheus
    • 7.07 Middleware-错误页面
    • 7.08 Middleware-从panic中恢复
    • 7.09 Middleware总结和面试
  • PART08.Review
    • 8.01 课后复习-AOP
    • 8.02 课后复习-Context
    • 8.03 课后复习-Middleware-AccessLog
  • PART09.Appendix
    • 附录1.责任链模式
    • 附录2.生成器模式
    • 附录3.函数选项模式
  • xiaochengxu
    • 01.原力去水印
    • 02.KeePass密码管理:安全轻松的管理您的密码
Powered by GitBook
On this page
  • PART1. 概念示例
  • 1.1 背景故事
  • 1.2 房屋结构体
  • 1.3 生成器接口
  • 1.4 普通房屋生成器
  • 1.5 冰屋生成器
  • 1.6 管理者结构体
  • 1.7 提供对外暴露的创建具体生成器的方法
  • 1.8 客户端创建房屋
  • PART2. 示例相关UML
  • PART3. 生成器模式工作流程
  • PART4. 生成器模式使用场景
  • PART5. 生成器模式的优缺点
  • 5.1 优点
  • 5.2 缺点
  1. PART09.Appendix

附录2.生成器模式

生成器模式是一种创建型设计模式,使你能够分步骤创建复杂对象.

与其他创建型模式不同,生成器模式不要求产品拥有通用接口.这使得用相同的创建过程生成不同的产品成为可能.

PART1. 概念示例

当所需产品较为复杂且需要多个步骤才能完成时,可以使用生成器模式.在这种情况下,使用多个构造方法比仅仅使用一个复杂可怕的构造函数更简单.但分多个步骤进行构建的策略也有其问题.分为多个步骤进行构建的潜在问题在于:构建不完整的和不稳定的产品可能会被暴露给客户端.生成器模式能够在产品完成构建之前使其处于私密状态.

1.1 背景故事

现有2种房屋:

  • 冰屋

  • 普通房屋

这两种房屋的建造步骤都是相同的(例如先装窗户、再装门,最后装地板).该如何组织这个建造过程?

1.2 房屋结构体

房屋结构体实际上就是我们完成所有建造步骤后,最终对外提供的产品

pattern/house.go:

package pattern

// House 房屋结构体 即最终对外提供的产品
type House struct {
	windowType string // windowType 窗户类型
	doorType   string // doorType 门的类型
	floor      int    // floor 房屋楼层数
}

// GetWindowType 本方法用于获取房屋的窗户类型
func (h House) GetWindowType() string {
	return h.windowType
}

// GetDoorType 本方法用于获取房屋的门的类型
func (h House) GetDoorType() string {
	return h.doorType
}

// GetFloor 本方法用于获取房屋的楼层数
func (h House) GetFloor() int {
	return h.floor
}

1.3 生成器接口

接口定义行为.本例中的生成器接口定义了创建一个房屋所必须经历的过程,也就是创建一个房屋的行为

pattern/iBuilder.go

package pattern

// IBuilder 生成器接口 本接口用于定义创建房屋的必要过程
type IBuilder interface {
	setWindowType()  // setWindowType 本方法用于设置窗户类型
	setDoorType()    // setDoorType 本方法用于设置门的类型
	setFloor()       // setFloor 本方法用于设置房屋楼层数
	getHouse() House // getHouse 本方法用于创建并返回房屋
}

1.4 普通房屋生成器

pattern/normalBuilder.go:

package pattern

// NormalBuilder 普通房屋生成器
type NormalBuilder struct {
	windowType string // windowType 普通房屋的窗户类型
	doorType   string // doorType 普通房屋的门的类型
	floor      int    // floor 普通房屋的房屋楼层数
}

// newNormalBuilder NormalBuilder 的构造函数
func newNormalBuilder() *NormalBuilder {
	return &NormalBuilder{}
}

// setWindowType 本方法用于设置普通房屋的窗户类型
func (b *NormalBuilder) setWindowType() {
	b.windowType = "木窗户"
}

// setDoorType 本方法用于设置普通房屋的门类型
func (b *NormalBuilder) setDoorType() {
	b.doorType = "木门"
}

// setFloor 本方法用于设置普通房屋的楼层数
func (b *NormalBuilder) setFloor() {
	b.floor = 2
}

// getHouse 本方法用于创建普通房屋
func (b *NormalBuilder) getHouse() House {
	return House{
		windowType: b.windowType,
		doorType:   b.doorType,
		floor:      b.floor,
	}
}

1.5 冰屋生成器

pattern/iglooBuilder.go:

package pattern

// IglooBuilder 冰屋生成器
type IglooBuilder struct {
	windowType string // windowType 冰屋的窗户类型
	doorType   string // doorType 冰屋的门的类型
	floor      int    // floor 冰屋的房屋楼层数
}

// newIglooBuilder IglooBuilder 的构造函数
func newIglooBuilder() *IglooBuilder {
	return &IglooBuilder{}
}

// setWindowType 本方法用于设置冰屋的窗户类型
func (b *IglooBuilder) setWindowType() {
	b.windowType = "雪窗户"
}

// setDoorType 本方法用于设置冰屋的门类型
func (b *IglooBuilder) setDoorType() {
	b.doorType = "雪门"
}

// setFloor 本方法用于设置冰屋的楼层数
func (b *IglooBuilder) setFloor() {
	b.floor = 1
}

// getHouse 本方法用于创建冰屋
func (b *IglooBuilder) getHouse() House {
	return House{
		windowType: b.windowType,
		doorType:   b.doorType,
		floor:      b.floor,
	}
}

1.6 管理者结构体

以上两个具体的生成器类仅仅定义了建造一个房屋(无论是普通房屋还是冰屋)的每个具体过程,但还缺少一个角色,该角色用于编排这些过程的执行顺序.在本例中,可以理解为:无论是建造一个冰屋还是普通房屋,其建造顺序应该是固定的:

  • step1. 造窗户

  • step2. 造门

  • step3. 确定楼层数

而管理者结构体的职责就是确定这些过程的执行顺序,并在这些过程都按顺序执行完毕后,返回被创建出的产品

pattern/director.go:

package pattern

// Director 管理者结构体 本结构体用于编排生成器的生成过程 并最终生成产品
// 本结构体的存在使得客户端不必关心生成器的生成过程
type Director struct {
	builder IBuilder // builder 生成器接口的实现
}

// NewDirector Director 的构造函数
func NewDirector(builder IBuilder) *Director {
	return &Director{
		builder: builder,
	}
}

// SetBuilder 本方法用于为管理者结构体设置具体生成器
// 本方法存在的意义在于可以在运行时动态的改变管理者实例中的生成器实例
func (d *Director) SetBuilder(builder IBuilder) {
	d.builder = builder
}

// BuildHouse 本方法用于编排具体生成器的生成过程 并最终生成产品
func (d *Director) BuildHouse() House {
	d.builder.setWindowType()
	d.builder.setDoorType()
	d.builder.setFloor()
	return d.builder.getHouse()
}

1.7 提供对外暴露的创建具体生成器的方法

pattern/IBuilder.go:

package pattern

// IBuilder 生成器接口 本接口用于定义创建房屋的必要过程
type IBuilder interface {
	setWindowType()  // setWindowType 本方法用于设置窗户类型
	setDoorType()    // setDoorType 本方法用于设置门的类型
	setFloor()       // setFloor 本方法用于设置房屋楼层数
	getHouse() House // getHouse 本方法用于创建并返回房屋
}

// GetBuilder 本函数用于根据给定的生成器类型 创建具体生成器
func GetBuilder(builderType string) IBuilder {
	switch builderType {
	case "normal":
		return newNormalBuilder()
	case "igloo":
		return newIglooBuilder()
	default:
		return nil
	}
}

1.8 客户端创建房屋

main.go:

package main

import (
	"builder/pattern"
	"fmt"
)

func main() {
	// 普通房屋生成器实例
	normalBuilder := pattern.GetBuilder("normal")
	// 冰屋生成器实例
	iglooBuilder := pattern.GetBuilder("igloo")

	// 管理者实例
	director := pattern.NewDirector(normalBuilder)
	// 生成普通房屋
	normalHouse := director.BuildHouse()

	fmt.Printf("普通房屋的窗户类型: %s\n", normalHouse.GetWindowType())
	fmt.Printf("普通房屋的门的类型: %s\n", normalHouse.GetDoorType())
	fmt.Printf("普通房屋的楼层数: %d\n", normalHouse.GetFloor())

	// 重置管理者实例中的生成器实例
	director.SetBuilder(iglooBuilder)
	// 生成冰屋
	iglooHouse := director.BuildHouse()

	fmt.Printf("冰屋的窗户类型: %s\n", iglooHouse.GetWindowType())
	fmt.Printf("冰屋的门的类型: %s\n", iglooHouse.GetDoorType())
	fmt.Printf("冰屋的楼层数: %d\n", iglooHouse.GetFloor())
}

执行结果:

普通房屋的窗户类型: 木窗户
普通房屋的门的类型: 木门
普通房屋的楼层数: 2
冰屋的窗户类型: 雪窗户
冰屋的门的类型: 雪门
冰屋的楼层数: 1

PART2. 示例相关UML

PART3. 生成器模式工作流程

PART4. 生成器模式使用场景

  • 当开发者希望创建不同形式的产品时,可以使用生成器模式

  • 如果开发者需要创建各种形式的产品,且这些产品的制造过程相似,且产品之间的差别不大(例如本例中的冰屋和普通房屋),可以使用生成器模式

  • 如果需要使用构造函数,且构造函数中的参数很多时,可以使用生成器模式

  • 当需要构建同一个对象的不同表示时,可以使用生成器模式.换言之,当需要创建具有不同特征的同一类对象时,可使用生成器模式

PART5. 生成器模式的优缺点

5.1 优点

  • 在生成器模式中,产品内部组成的细节对客户端不可见,将产品的创建过程和产品自身解耦,使相同的创建过程可以创建不同的产品对象

  • 在生成器模式中,每个具体生成器都相对独立,因此可以十分方便地替换具体生成器或增加新的具体生成器,且无须修改原有类库的代码(无侵入式的修改才是高明的修改),系统扩展方便,符合开闭原则(Open/Closed Principle,OCP),设计灵活性和代码可读性较高

  • 生成器模式可以将复杂产品的创建步骤分解在不同的方法中,使创建过程更清晰,更易于使用程序控制创建过程

5.2 缺点

  • 使用生成器模式创建的产品组成部分都类似,如果不同产品之间的差异很大(如很多组成部分都不相同),则不适合使用生成器模式,因此其使用范围有限

  • 在生成器模式中,需要为不同类型的产品创建单独的具体生成器,因此代码量较大.如果系统比较大,则会增加系统的理解难度和运行成本

Last updated 1 year ago

生成器模式UML
生成器模式工作流程