策略模式strategy

为什么要用策略模式

在有多种算法相似的情况下，使用 if…else 所带来的复杂和难以维护。

1. 实现一个计算类Operator，当用户输入全校学生的各科成绩，计算平均分，方差等等。如果使用硬编码，那么每次添加一种计算类型(比如后续可能添加中位数的计算方法)，都要修改Operator类。而且这个Operator类将来会变的巨大无比，难以修改。
2. 所以我们就希望将计算方法从Operator类剔除出去，使用组合的方法来实现。

解决方法

• 策略模式建议找出负责用许多不同方式完成特定任务的类，然后将其中的算法抽取到一组被称为策略的独立类中。
• 名为上下文的原始类必须包含一个成员变量来存储对于每种策略的引用。上下文并不执行任务，而是将工作委派给已连接的策略对象。
• 上下文不负责选择符合任务需要的算法——客户端会将所需策略传递给上下文。实际上，上下文并不十分了解策略，它会通过同样的通用接口与所有策略进行交互，而该接口只需暴露一个方法来触发所选策略中封装的算法即可。

因此，上下文可独立于具体策略。这样你就可在不修改上下文代码或其他策略的情况下添加新算法或修改已有算法了。

策略模式结构

策略模式适合应用场景

• 当你想使用对象中各种不同的算法变体，并希望能在运行时切换算法时，可使用策略模式。

  策略模式让你能够将对象关联至可以不同方式执行特定子任务的不同子对象，从而以间接方式在运行时更改对象行为。

• 当你有许多仅在执行某些行为时略有不同的相似类时，可使用策略模式。

  策略模式让你能将不同行为抽取到一个独立类层次结构中，并将原始类组合成同一个，从而减少重复代码。

• 如果算法在上下文的逻辑中不是特别重要，使用该模式能将类的业务逻辑与其算法实现细节隔离开来。

  策略模式让你能将各种算法的代码、 内部数据和依赖关系与其他代码隔离开来。不同客户端可通过一个简单接口执行算法，并能在运行时进行切换。

• 当类中使用了复杂条件运算符以在同一算法的不同变体中切换时，可使用该模式。

  策略模式将所有继承自同样接口的算法抽取到独立类中，因此不再需要条件语句。原始对象并不实现所有算法的变体，而是将执行工作委派给其中的一个独立算法对象。

实现方式

1. 从上下文类中找出修改频率较高的算法 （也可能是用于在运行时选择某个算法变体的复杂条件运算符）。
2. 声明该算法所有变体的通用策略接口。
3. 将算法逐一抽取到各自的类中，它们都必须实现策略接口。
4. 在上下文类中添加一个成员变量用于保存对于策略对象的引用。然后提供设置器以修改该成员变量。上下文仅可通过策略接口同策略对象进行交互，如有需要还可定义一个接口来让策略访问其数据。
5. 客户端必须将上下文类与相应策略进行关联，使上下文可以预期的方式完成其主要工作。

代码实现

package pattern_dive

import (
	"fmt"
	"testing"
)

// 移除算法
type evictionAlgo interface {
	// 移除函数
	evict(c *cache)
}

// 先进先出 （FIFO）： 移除最早创建的条目。
type fifo struct {}
func (l *fifo) evict(c *cache) {
	fmt.Println("Evicting by fifo strtegy")
}

// 最少最近使用 （LRU）： 移除最近使用最少的一条条目。
type lru struct {}
func (l *lru) evict(c *cache) {
	fmt.Println("Evicting by lru strtegy")
}

// 最少使用 （LFU）： 移除使用频率最低一条条目。
type lfu struct {}
func (l *lfu) evict(c *cache) {
	fmt.Println("Evicting by lfu strtegy")
}

type cache struct {
	storage      map[string]string
	evictionAlgo evictionAlgo
	capacity     int
	maxCapacity  int
}

func initCache(e evictionAlgo) *cache {
	storage := make(map[string]string)
	return &cache{
		storage:      storage,
		evictionAlgo: e,
		capacity:     0,
		maxCapacity:  2,
	}
}

func (c *cache) setEvictionAlgo(e evictionAlgo) {
	c.evictionAlgo = e
}

func (c *cache) add(key, value string) {
	if c.capacity == c.maxCapacity {
		c.evict()
	}
	c.capacity++
	c.storage[key] = value
}

func (c *cache) get(key string) {
	delete(c.storage, key)
}

func (c *cache) evict() {
	c.evictionAlgo.evict(c)
	c.capacity--
}

func TestStrategy(t *testing.T) {
	lfu := &lfu{}
	cache := initCache(lfu)

	cache.add("a", "1")
	cache.add("b", "2")
	cache.add("c", "3")

	lru := &lru{}
	cache.setEvictionAlgo(lru)

	cache.add("d", "4")

	fifo := &fifo{}
	cache.setEvictionAlgo(fifo)

	cache.add("e", "5")
}

某些语言支持匿名函数，所以策略不仅可以是一个类，还可以是一个function

package pattern_me

import (
	"fmt"
	"testing"
)

type StrategyFunc = func(a, b int) int

// 具体策略的执行者
type Operator struct {
	strategy StrategyFunc
}

// 设置策略
func (operator *Operator) setStrategy(strategy StrategyFunc) {
	operator.strategy = strategy
}

// 调用策略中的方法
func (operator *Operator) calculate(a, b int) int {
	return operator.strategy(a, b)
}

func TestStrategy(t *testing.T) {
	operator := Operator{}

	add := func(a, b int) int { return a + b }
	reduce := func(a, b int) int { return a - b }

	operator.setStrategy(add)
	result := operator.calculate(1, 2)
	fmt.Println("add:", result)

	operator.setStrategy(reduce)
	result = operator.calculate(2, 1)
	fmt.Println("reduce:", result)
}

策略模式优缺点

• 你可以在运行时切换对象内的算法。
• 你可以将算法的实现和使用算法的代码隔离开来。
• 你可以使用组合来代替继承。
• 开闭原则。你无需对上下文进行修改就能够引入新的策略。

• 如果你的算法极少发生改变，那么没有任何理由引入新的类和接口。使用该模式只会让程序过于复杂。
• 客户端必须知晓策略间的不同——它需要选择合适的策略。
• 许多现代编程语言支持函数类型功能，允许你在一组匿名函数中实现不同版本的算法。这样，你使用这些函数的方式就和使用策略对象时完全相同，无需借助额外的类和接口来保持代码简洁。

与其他模式的关系

• 桥接模式、 状态模式和策略模式 （在某种程度上包括适配器模式） 模式的接口非常相似。实际上，它们都基于组合模式——即将工作委派给其他对象，不过也各自解决了不同的问题。模式并不只是以特定方式组织代码的配方，你还可以使用它们来和其他开发者讨论模式所解决的问题。
• 命令模式和策略看上去很像，因为两者都能通过某些行为来参数化对象。但是，它们的意图有非常大的不同。
  • 你可以使用命令来将任何操作转换为对象。操作的参数将成为对象的成员变量。你可以通过转换来延迟操作的执行、 将操作放入队列、 保存历史命令或者向远程服务发送命令等。
  • 另一方面，策略通常可用于描述完成某件事的不同方式，让你能够在同一个上下文类中切换算法。
• 装饰模式可让你更改对象的外表，策略则让你能够改变其本质。
• 模板方法模式基于继承机制： 它允许你通过扩展子类中的部分内容来改变部分算法。策略基于组合机制： 你可以通过对相应行为提供不同的策略来改变对象的部分行为。模板方法在类层次上运作，因此它是静态的。策略在对象层次上运作，因此允许在运行时切换行为。
• 状态可被视为策略的扩展。两者都基于组合机制： 它们都通过将部分工作委派给 “帮手” 对象来改变其在不同情景下的行为。策略使得这些对象相互之间完全独立，它们不知道其他对象的存在。但状态模式没有限制具体状态之间的依赖，且允许它们自行改变在不同情景下的状态。

观察者模式Observer

观察者模式是一种行为设计模式，允许你定义一种订阅机制，可在对象事件发生时通知多个 “观察” 该对象的其他对象。

为什么要用观察者模式

就像微信公众号订阅系统

• 系统需要主动推送信息到客户
• 没有订阅的客户不能收到那些公众号的消息推送

解决方法

• 拥有一些值得关注的状态的对象通常被称为目标，
• 由于它要将自身的状态改变通知给其他对象，我们也将其称为发布者 （publisher）。
• 所有希望关注发布者状态变化的其他对象被称为订阅者 （subscribers）。

观察者模式建议你为发布者类添加订阅机制，让每个对象都能订阅或取消订阅发布者事件流。实际上，该机制包括

1. 一个用于存储订阅者对象引用的列表成员变量；
2. 几个用于添加或删除该列表中订阅者的公有方法。

现在，无论何时发生了重要的发布者事件，它都要遍历订阅者并调用其对象的特定通知方法。

实际应用中可能会有十几个不同的订阅者类跟踪着同一个发布者类的事件，你不会希望发布者与所有这些类相耦合的。此外如果他人会使用发布者类，那么你甚至可能会对其中的一些类一无所知。

因此，所有订阅者都必须实现同样的接口，发布者仅通过该接口与订阅者交互。接口中必须声明通知方法及其参数，这样发布者在发出通知时还能传递一些上下文数据。

如果你的应用中有多个不同类型的发布者，且希望订阅者可兼容所有发布者，那么你甚至可以进一步让所有订阅者遵循同样的接口。该接口仅需描述几个订阅方法即可。这样订阅者就能在不与具体发布者类耦合的情况下通过接口观察发布者的状态。

观察者模式结构

观察者模式适合应用场景

• 当一个对象状态的改变需要改变其他对象，或实际对象是事先未知的或动态变化的时，可使用观察者模式。

  当你使用图形用户界面类时通常会遇到一个问题。比如，你创建了自定义按钮类并允许客户端在按钮中注入自定义代码，这样当用户按下按钮时就会触发这些代码。

观察者模式允许任何实现了订阅者接口的对象订阅发布者对象的事件通知。你可在按钮中添加订阅机制，允许客户端通过自定义订阅类注入自定义代码。

• 当应用中的一些对象必须观察其他对象时，可使用该模式。但仅能在有限时间内或特定情况下使用。

  订阅列表是动态的，因此订阅者可随时加入或离开该列表。

实现方式

1. 仔细检查你的业务逻辑，试着将其拆分为两个部分： 独立于其他代码的核心功能将作为发布者； 其他代码则将转化为一组订阅类。

2. 声明订阅者接口。该接口至少应声明一个 update方法。

3. 声明发布者接口并定义一些接口来在列表中添加和删除订阅对象。记住发布者必须仅通过订阅者接口与它们进行交互。

4. 确定存放实际订阅列表的位置并实现订阅方法。通常所有类型的发布者代码看上去都一样，因此将列表放置在直接扩展自发布者接口的抽象类中是显而易见的。具体发布者会扩展该类从而继承所有的订阅行为。

   但是，如果你需要在现有的类层次结构中应用该模式，则可以考虑使用组合的方式： 将订阅逻辑放入一个独立的对象，然后让所有实际订阅者使用该对象。

5. 创建具体发布者类。每次发布者发生了重要事件时都必须通知所有的订阅者。

6. 在具体订阅者类中实现通知更新的方法。绝大部分订阅者需要一些与事件相关的上下文数据。这些数据可作为通知方法的参数来传递。

   但还有另一种选择。订阅者接收到通知后直接从通知中获取所有数据。在这种情况下，发布者必须通过更新方法将自身传递出去。另一种不太灵活的方式是通过构造函数将发布者与订阅者永久性地连接起来。

7. 客户端必须生成所需的全部订阅者，并在相应的发布者处完成注册工作。

代码实现

package pattern_dive

import (
	"fmt"
	"testing"
)

type subject interface {
	register(Observer observer)
	deregister(Observer observer)
	notifyAll()
}

type item struct {
	observerList []observer
	name         string
	inStock      bool
}

func newItem(name string) *item {
	return &item{name: name}
}
func (i *item) updateAvailability() {
	fmt.Printf("Item %s is now in stock\n", i.name)
	i.inStock = true
	i.notifyAll()
}
func (i *item) register(o observer) {
	i.observerList = append(i.observerList, o)
}

func (i *item) deregister(o observer) {
	i.observerList = removeFromSlice(i.observerList, o)
}

func (i *item) notifyAll() {
	for _, observer := range i.observerList {
		observer.update(i.name)
	}
}

func removeFromSlice(observerList []observer, observerToRemove observer) []observer {
	observerListLength := len(observerList)
	for i, observer := range observerList {
		if observerToRemove.getID() == observer.getID() {
			observerList[observerListLength-1], observerList[i] = observerList[i], observerList[observerListLength-1]
			return observerList[:observerListLength-1]
		}
	}
	return observerList
}

type observer interface {
	update(string)
	getID() string
}

type customer struct {
	id string
}
func (c *customer) update(itemName string) {
	fmt.Printf("Sending email to customer %s for item %s\n", c.id, itemName)
}
func (c *customer) getID() string {
	return c.id
}

func TestObserver(t *testing.T) {
	shirtItem := newItem("Nike Shirt")

	observerFirst := &customer{id: "abc@gmail.com"}
	observerSecond := &customer{id: "xyz@gmail.com"}

	shirtItem.register(observerFirst)
	shirtItem.register(observerSecond)

	shirtItem.updateAvailability()
}

注意：观察者本身也可以是发布者

package pattern_me

import (
	"fmt"
	"testing"
)

type Observer interface {
	update()
}

type FirstObserver struct{}
func (o *FirstObserver) update() {
	fmt.Println("this is firstObserver update")
	fmt.Println("firstObserver update done")
}

type ObserverPublisher struct {
	observers []Observer
}
func (o *ObserverPublisher) update() {
	fmt.Println("this is ObserverPublisher update")
	o.notify()
	fmt.Println("ObserverPublisher update done")
}
func (o *ObserverPublisher) addObserver(observer Observer) {
	o.observers = append(o.observers, observer)
}
func (o *ObserverPublisher) notify() {
	for _, ob := range o.observers {
		ob.update()
	}
}

type Publisher interface {
	notify()
	addObserver(observer Observer)
}

type RootPublisher struct {
	observers []Observer
}
func (r *RootPublisher) addObserver(observer Observer) {
	r.observers = append(r.observers, observer)
}
func (r *RootPublisher) notify() {
	for _, ob := range r.observers {
		ob.update()
	}
}

func TestSecondObserver(t *testing.T) {
	r := &RootPublisher{}

	firstObserver1 := &FirstObserver{}
	firstObserver2 := &FirstObserver{}

	firstObserver3 := &FirstObserver{}
	secondObserver1 := &ObserverPublisher{}
	secondObserver1.addObserver(firstObserver3)

	r.addObserver(firstObserver1)
	r.addObserver(firstObserver2)
	r.addObserver(secondObserver1)

	r.notify()
}

观察者模式优缺点

• 开闭原则。你无需修改发布者代码就能引入新的订阅者类 （如果是发布者接口则可轻松引入发布者类）。
• 你可以在运行时建立对象之间的联系。

• 订阅者的通知顺序是随机的。

与其他模式的关系

• 责任链模式、 命令模式、 中介者模式和观察者模式用于处理请求发送者和接收者之间的不同连接方式：
  • 责任链按照顺序将请求动态传递给一系列的潜在接收者，直至其中一名接收者对请求进行处理。
  • 命令在发送者和请求者之间建立单向连接。
  • 中介者清除了发送者和请求者之间的直接连接，强制它们通过一个中介对象进行间接沟通。
  • 观察者允许接收者动态地订阅或取消接收请求。
• 中介者和观察者之间的区别往往很难记住。在大部分情况下，你可以使用其中一种模式，而有时可以同时使用。让我们来看看如何做到这一点。
  • 中介者的主要目标是消除一系列系统组件之间的相互依赖。这些组件将依赖于同一个中介者对象。观察者的目标是在对象之间建立动态的单向连接，使得部分对象可作为其他对象的附属发挥作用。
  • 有一种流行的中介者模式实现方式依赖于观察者。中介者对象担当发布者的角色，其他组件则作为订阅者，可以订阅中介者的事件或取消订阅。当中介者以这种方式实现时，它可能看上去与观察者非常相似。
  • 当你感到疑惑时，记住可以采用其他方式来实现中介者。例如，你可永久性地将所有组件链接到同一个中介者对象。这种实现方式和观察者并不相同，但这仍是一种中介者模式。
  • 假设有一个程序，其所有的组件都变成了发布者，它们之间可以相互建立动态连接。这样程序中就没有中心化的中介者对象，而只有一些分布式的观察者。

装饰模式Decorator

装饰模式是一种结构型设计模式，允许你通过将对象放入包含行为的特殊封装对象中来为原对象绑定新的行为。

为什么使用装饰模式

• 主要是为了解决功能的自由组合问题。一杯奶茶，可以去冰/少冰/多冰，可以加果粒/珍珠，可以常温/冷/热。不同的维度有不同的选择。此时要创建一个【去冰加珍珠常温奶茶】。如果使用子类的话，子类的数量会在不经意之间打破吉尼斯纪录。
• 动态地给一个对象添加一些额外的职责。比如一个函数，加入计时功能，显然计时功能如果加入函数代码里面，就会造成污染。

穿衣服是使用装饰的一个例子。觉得冷时，你可以穿一件毛衣。如果穿毛衣还觉得冷，你可以再套上一件夹克。如果遇到下雨，你还可以再穿一件雨衣。所有这些衣物都 “扩展” 了你的基本行为，但它们并不是你的一部分，如果你不再需要某件衣物，可以方便地随时脱掉。

解决方案

当你需要更改一个对象的行为时，第一个跳入脑海的想法就是扩展它所属的类。但是，你不能忽视继承可能引发的几个严重问题。

• 继承是静态的。你无法在运行时更改已有对象的行为，只能使用由不同子类创建的对象来替代当前的整个对象。
• 子类只能有一个父类。大部分编程语言不允许一个类同时继承多个类的行为。

其中一种方法是用聚合或组合 ，而不是继承。两者的工作方式几乎一模一样： 一个对象包含指向另一个对象的引用，并将部分工作委派给引用对象； 继承中的对象则继承了父类的行为，它们自己能够完成这些工作。

你可以使用这个新方法来轻松替换各种连接的 “小帮手” 对象，从而能在运行时改变容器的行为。一个对象可以使用多个类的行为，包含多个指向其他对象的引用，并将各种工作委派给引用对象。

聚合 （或组合） 组合是许多设计模式背后的关键原则 （包括装饰在内）。记住这一点后，让我们继续关于模式的讨论。

封装器是装饰模式的别称，这个称谓明确地表达了该模式的主要思想。 “封装器” 是一个能与其他 “目标” 对象连接的对象。封装器包含与目标对象相同的一系列方法，它会将所有接收到的请求委派给目标对象。但是，封装器可以在将请求委派给目标前后对其进行处理，所以可能会改变最终结果。

那么什么时候一个简单的封装器可以被称为是真正的装饰呢？ 正如之前提到的，封装器实现了与其封装对象相同的接口。因此从客户端的角度来看，这些对象是完全一样的。封装器中的引用成员变量可以是遵循相同接口的任意对象。这使得你可以将一个对象放入多个封装器中，并在对象中添加所有这些封装器的组合行为。

比如在消息通知示例中，我们可以将简单邮件通知行为放在基类 通知器中，但将所有其他通知方法放入装饰中。

将各种通知方法放入装饰。

客户端代码必须将基础通知器放入一系列自己所需的装饰中。因此最后的对象将形成一个栈结构。

程序可以配置由通知装饰构成的复杂栈。

实际与客户端进行交互的对象将是最后一个进入栈中的装饰对象。由于所有的装饰都实现了与通知基类相同的接口，客户端的其他代码并不在意自己到底是与 “纯粹” 的通知器对象，还是与装饰后的通知器对象进行交互。

我们可以使用相同方法来完成其他行为 （例如设置消息格式或者创建接收人列表）。只要所有装饰都遵循相同的接口，客户端就可以使用任意自定义的装饰来装饰对象。

装饰模式结构

装饰模式适合应用场景

如果你希望在无需修改代码的情况下即可使用对象，且希望在运行时为对象新增额外的行为，可以使用装饰模式。

装饰能将业务逻辑组织为层次结构，你可为各层创建一个装饰，在运行时将各种不同逻辑组合成对象。由于这些对象都遵循通用接口，客户端代码能以相同的方式使用这些对象。

如果用继承来扩展对象行为的方案难以实现或者根本不可行，你可以使用该模式。

许多编程语言使用 final最终关键字来限制对某个类的进一步扩展。复用最终类已有行为的唯一方法是使用装饰模式： 用封装器对其进行封装。

实现方式

1. 确保业务逻辑可用一个基本组件及多个额外可选层次表示。
2. 找出基本组件和可选层次的通用方法。创建一个组件接口并在其中声明这些方法。
3. 创建一个具体组件类，并定义其基础行为。
4. 创建装饰基类，使用一个成员变量存储指向被封装对象的引用。该成员变量必须被声明为组件接口类型，从而能在运行时连接具体组件和装饰。装饰基类必须将所有工作委派给被封装的对象。
5. 确保所有类实现组件接口。
6. 将装饰基类扩展为具体装饰。具体装饰必须在调用父类方法 （总是委派给被封装对象） 之前或之后执行自身的行为。
7. 客户端代码负责创建装饰并将其组合成客户端所需的形式。

代码实现

package perttern

import (
	"fmt"
)

//  饮料接口
type Beverage interface {
	getDescription() string
	cost() int
}

// 实现咖啡的过程
type Coffee struct {
	description string
}
func (this Coffee) getDescription() string {
	return this.description
}
func (this Coffee) cost() int {
	return 1
}

// Mocha 实现
type Mocha struct {
	beverage    Beverage
	description string
}

func (this Mocha) getDescription() string {
	// 使用了委托
	return fmt.Sprintf("%s, %s", this.beverage.getDescription(), this.description)
}
func (this Mocha) cost() int {
	return this.beverage.cost() + 1
}

// Whip 实现
type Whip struct {
	beverage    Beverage
	description string
}

func (this Whip) getDescription() string {
	return fmt.Sprintf("%s, %s", this.beverage.getDescription(), this.description)
}
func (this Whip) cost() int {
	return this.beverage.cost() + 1
}

func main() {
	var beverage Beverage
	// 买了一杯咖啡
	beverage = Coffee{description: "houseBlend"}
	// 给咖啡加上 Mocha
	beverage = Mocha{beverage: beverage, description: "Mocha"}
	// 给咖啡加上 Whip
	beverage = Whip{beverage: beverage, description: "whip"}
	// 最后计算 Coffee 的价格
	fmt.Println(beverage.getDescription(), ", cost is ", beverage.cost())
}

package pattern_me

import (
	"fmt"
	"testing"
	"time"
)

type Func func(a, b int) int

func Add(a, b int) int {
	return a + b
}

func Logger(f Func) Func {
	return func(a, b int) int {
		t1 := time.Now()
		res := f(a, b)
		fmt.Println("App elapsed: ", time.Since(t1))
		return res
	}
}

func TestDecoratorFunc(t *testing.T) {
	add := Logger(Add)
	add(1, 2)
}

装饰模式优缺点

• 你无需创建新子类即可扩展对象的行为。
• 你可以在运行时添加或删除对象的功能。
• 你可以用多个装饰封装对象来组合几种行为。
• 单一职责原则。你可以将实现了许多不同行为的一个大类拆分为多个较小的类。

• 在封装器栈中删除特定封装器比较困难。
• 实现行为不受装饰栈顺序影响的装饰比较困难。
• 各层的初始化配置代码看上去可能会很糟糕。

与其他模式的关系

• 适配器模式可以对已有对象的接口进行修改，装饰模式则能在不改变对象接口的前提下强化对象功能。此外，装饰还支持递归组合，适配器则无法实现。

• 适配器能为被封装对象提供不同的接口，代理模式能为对象提供相同的接口，装饰则能为对象提供加强的接口。

• 责任链模式和装饰模式的类结构非常相似。两者都依赖递归组合将需要执行的操作传递给一系列对象。但是，两者有几点重要的不同之处。

  责任链的管理者可以相互独立地执行一切操作，还可以随时停止传递请求。另一方面，各种装饰可以在遵循基本接口的情况下扩展对象的行为。此外，装饰无法中断请求的传递。

• 组合模式和装饰的结构图很相似，因为两者都依赖递归组合来组织无限数量的对象。

  装饰类似于组合，但其只有一个子组件。此外还有一个明显不同： 装饰为被封装对象添加了额外的职责，组合仅对其子节点的结果进行了 “求和”。

  但是，模式也可以相互合作： 你可以使用装饰来扩展组合树中特定对象的行为。

• 大量使用组合和装饰的设计通常可从对于原型模式的使用中获益。你可以通过该模式来复制复杂结构，而非从零开始重新构造。

• 装饰可让你更改对象的外表，策略模式则让你能够改变其本质。

• 装饰和代理有着相似的结构，但是其意图却非常不同。这两个模式的构建都基于组合原则，也就是说一个对象应该将部分工作委派给另一个对象。两者之间的不同之处在于代理通常自行管理其服务对象的生命周期，而装饰的生成则总是由客户端进行控制。

工厂方法模式Factory Method

工厂方法模式是一种创建型设计模式，其在父类中提供一个创建对象的方法，允许子类决定实例化对象的类型。

为什么使用工厂方法

简单工厂如下，如果后续需要添加iphone，三星，HTC，每次都要加入if-else，不仅破坏了开闭原则，而且GetPhone会越来越大

type Factory struct {}
func (f *Factory) GetPhone(name string) Phone {
	var p Phone
	if name == "xiaomi" {
		p = &XiaomiPhone{}
	} else if name == "huawei" {
		p = &HuaweiPhone{}
	}
	return p
}

解决方案

工厂方法模式建议使用特殊的工厂方法代替对于对象构造函数的直接调用 （即使用 new运算符）。工厂方法返回的对象通常被称作 “产品”。

工厂方法模式结构

工厂方法模式适合应用场景

• 当你在编写代码的过程中，如果无法预知对象确切类别及其依赖关系时，可使用工厂方法。

  工厂方法将创建产品的代码与实际使用产品的代码分离，从而能在不影响其他代码的情况下扩展产品创建部分代码。

  例如，如果需要向应用中添加一种新产品，你只需要开发新的创建者子类，然后重写其工厂方法即可。

• 如果你希望用户能扩展你软件库或框架的内部组件，可使用工厂方法。

  继承可能是扩展软件库或框架默认行为的最简单方法。但是当你使用子类替代标准组件时，框架如何辨识出该子类？

  解决方案是将各框架中构造组件的代码集中到单个工厂方法中，并在继承该组件之外允许任何人对该方法进行重写。

  让我们看看具体是如何实现的。假设你使用开源 UI 框架编写自己的应用。你希望在应用中使用圆形按钮，但是原框架仅支持矩形按钮。你可以使用 圆形按钮Round­Button子类来继承标准的 按钮Button类。但是，你需要告诉 UI框架UIFramework类使用新的子类按钮代替默认按钮。

  为了实现这个功能，你可以根据基础框架类开发子类 圆形按钮 UIUIWith­Round­Buttons ，并且重写其 create­Button创建按钮方法。基类中的该方法返回 按钮对象，而你开发的子类返回 圆形按钮对象。现在，你就可以使用 圆形按钮 UI类代替 UI框架类。就是这么简单！

• 如果你希望复用现有对象来节省系统资源，而不是每次都重新创建对象，可使用工厂方法。

  在处理大型资源密集型对象 （比如数据库连接、 文件系统和网络资源） 时，你会经常碰到这种资源需求。

  让我们思考复用现有对象的方法：

  1. 首先，你需要创建存储空间来存放所有已经创建的对象。
  2. 当他人请求一个对象时，程序将在对象池中搜索可用对象。
  3. …然后将其返回给客户端代码。
  4. 如果没有可用对象，程序则创建一个新对象 （并将其添加到对象池中）。

  这些代码可不少！ 而且它们必须位于同一处，这样才能确保重复代码不会污染程序。

  可能最显而易见，也是最方便的方式，就是将这些代码放置在我们试图重用的对象类的构造函数中。但是从定义上来讲，构造函数始终返回的是新对象，其无法返回现有实例。

  因此，你需要有一个既能够创建新对象，又可以重用现有对象的普通方法。这听上去和工厂方法非常相像。

实现方式

1. 让所有产品都遵循同一接口。该接口必须声明对所有产品都有意义的方法。

2. 在创建类中添加一个空的工厂方法。该方法的返回类型必须遵循通用的产品接口。

3. 在创建者代码中找到对于产品构造函数的所有引用。将它们依次替换为对于工厂方法的调用，同时将创建产品的代码移入工厂方法。你可能需要在工厂方法中添加临时参数来控制返回的产品类型。

   工厂方法的代码看上去可能非常糟糕。其中可能会有复杂的 switch分支运算符，用于选择各种需要实例化的产品类。但是不要担心，我们很快就会修复这个问题。

4. 现在，为工厂方法中的每种产品编写一个创建者子类，然后在子类中重写工厂方法，并将基本方法中的相关创建代码移动到工厂方法中。

5. 如果应用中的产品类型太多，那么为每个产品创建子类并无太大必要，这时你也可以在子类中复用基类中的控制参数。

   例如，设想你有以下一些层次结构的类。基类 邮件及其子类 航空邮件和 陆路邮件 ； 运输及其子类 飞机, 卡车和 火车 。 航空邮件仅使用 飞机对象，而 陆路邮件则会同时使用 卡车和 火车对象。你可以编写一个新的子类 （例如 火车邮件 ） 来处理这两种情况，但是还有其他可选的方案。客户端代码可以给 陆路邮件类传递一个参数，用于控制其希望获得的产品。

6. 如果代码经过上述移动后，基础工厂方法中已经没有任何代码，你可以将其转变为抽象类。如果基础工厂方法中还有其他语句，你可以将其设置为该方法的默认行为。

代码实现

package pattern_dive_test

import (
	"fmt"
	"testing"
)

type iGun interface {
	setName(name string)
	setPower(power int)
	getName() string
	getPower() int
}

type gun struct {
	name  string
	power int
}

func (g *gun) setName(name string) {
	g.name = name
}

func (g *gun) getName() string {
	return g.name
}

func (g *gun) setPower(power int) {
	g.power = power
}

func (g *gun) getPower() int {
	return g.power
}

type ak47 struct {
	gun
}

func newAk47() iGun {
	return &ak47{
		gun: gun{
			name:  "AK47 gun",
			power: 4,
		},
	}
}

type musket struct {
	gun
}

func newMusket() iGun {
	return &musket{
		gun: gun{
			name:  "Musket gun",
			power: 1,
		},
	}
}

func getGun(gunType string) (iGun, error) {
	if gunType == "ak47" {
		return newAk47(), nil
	}
	if gunType == "musket" {
		return newMusket(), nil
	}
	return nil, fmt.Errorf("Wrong gun type passed")
}


func printDetails(g iGun) {
	fmt.Printf("Gun: %s", g.getName())
	fmt.Println()
	fmt.Printf("Power: %d", g.getPower())
	fmt.Println()
}

func TestFactoryMethod(t *testing.T) {
	ak47, _ := getGun("ak47")
	musket, _ := getGun("musket")

	printDetails(ak47)
	printDetails(musket)
}

工厂方法模式优缺点

• 你可以避免创建者和具体产品之间的紧密耦合。
• 单一职责原则。你可以将产品创建代码放在程序的单一位置，从而使得代码更容易维护。
• 开闭原则。无需更改现有客户端代码，你就可以在程序中引入新的产品类型。

• 应用工厂方法模式需要引入许多新的子类，代码可能会因此变得更复杂。最好的情况是将该模式引入创建者类的现有层次结构中。

抽象工厂模式Abstract Factory

抽象工厂模式是一种创建型设计模式，它能创建一系列相关的对象，而无需指定其具体类。

为什么要使用抽象工厂

假设你正在开发一款家具商店模拟器。你的代码中包括一些类，用于表示：

1. 一系列相关产品，例如 椅子Chair 、 沙发Sofa和 咖啡桌Coffee­Table 。

2. 系列产品的不同变体。例如，你可以使用 现代Modern 、 维多利亚Victorian 、 装饰风艺术Art­Deco等风格生成 椅子 、 沙发和 咖啡桌 。

   

你需要设法单独生成每件家具对象，这样才能确保其风格一致。如果顾客收到的家具风格不一样，他们可不会开心。此外，你也不希望在添加新产品或新风格时修改已有代码。家具供应商对于产品目录的更新非常频繁，你不会想在每次更新时都去修改核心代码的。

解决方案

首先，抽象工厂模式建议为系列中的每件产品明确声明接口 （例如椅子、 沙发或咖啡桌）。然后，确保所有产品变体都继承这些接口。例如，所有风格的椅子都实现 椅子接口； 所有风格的咖啡桌都实现 咖啡桌接口，以此类推。

接下来，我们需要声明抽象工厂——包含系列中所有产品构造方法的接口。例如 create­Chair创建椅子 、 create­Sofa创建沙发和 create­Coffee­Table创建咖啡桌 。这些方法必须返回抽象产品类型，即我们之前抽取的那些接口： 椅子 ， 沙发和 咖啡桌等等。

那么该如何处理产品变体呢？ 对于系列产品的每个变体，我们都将基于 抽象工厂接口创建不同的工厂类。每个工厂类都只能返回特定类别的产品，例如， 现代家具工厂Modern­Furniture­Factory只能创建 现代椅子Modern­Chair 、 现代沙发Modern­Sofa和 现代咖啡桌Modern­Coffee­Table对象。

客户端代码可以通过相应的抽象接口调用工厂和产品类。你无需修改实际客户端代码，就能更改传递给客户端的工厂类，也能更改客户端代码接收的产品变体。

假设客户端想要工厂创建一把椅子。客户端无需了解工厂类，也不用管工厂类创建出的椅子类型。无论是现代风格，还是维多利亚风格的椅子，对于客户端来说没有分别，它只需调用抽象 椅子接口就可以了。这样一来，客户端只需知道椅子以某种方式实现了 sit­On坐下方法就足够了。此外，无论工厂返回的是何种椅子变体，它都会和由同一工厂对象创建的沙发或咖啡桌风格一致。

最后一点说明： 如果客户端仅接触抽象接口，那么谁来创建实际的工厂对象呢？ 一般情况下，应用程序会在初始化阶段创建具体工厂对象。而在此之前，应用程序必须根据配置文件或环境设定选择工厂类别。

抽象工厂模式结构

抽象工厂模式适合应用场景

• 如果代码需要与多个不同系列的相关产品交互，但是由于无法提前获取相关信息，或者出于对未来扩展性的考虑，你不希望代码基于产品的具体类进行构建，在这种情况下，你可以使用抽象工厂。

  抽象工厂为你提供了一个接口，可用于创建每个系列产品的对象。只要代码通过该接口创建对象，那么你就不会生成与应用程序已生成的产品类型不一致的产品。

• 如果你有一个基于一组抽象方法的类，且其主要功能因此变得不明确，那么在这种情况下可以考虑使用抽象工厂模式。

  在设计良好的程序中，每个类仅负责一件事。如果一个类与多种类型产品交互，就可以考虑将工厂方法抽取到独立的工厂类或具备完整功能的抽象工厂类中。

实现方式

1. 以不同的产品类型与产品变体为维度绘制矩阵。
2. 为所有产品声明抽象产品接口。然后让所有具体产品类实现这些接口。
3. 声明抽象工厂接口，并且在接口中为所有抽象产品提供一组构建方法。
4. 为每种产品变体实现一个具体工厂类。
5. 在应用程序中开发初始化代码。该代码根据应用程序配置或当前环境，对特定具体工厂类进行初始化。然后将该工厂对象传递给所有需要创建产品的类。
6. 找出代码中所有对产品构造函数的直接调用，将其替换为对工厂对象中相应构建方法的调用。

代码实现

package perttern

import (
	"fmt"
	"testing"
)

type Phone interface {
	Call()
}

type MiaomiPhone struct{}
func (m *MiaomiPhone) Call() {
	fmt.Println("this is xiao mi call you")
}

type HuaweiPhone struct{}
func (h *HuaweiPhone) Call() {
	fmt.Println("this is hua wei call you")
}

type Computer interface {
	Play()
}

type MiaomiComputer struct{}
func (m *MiaomiComputer) Play() {
	fmt.Println("this is xiao mi play you")
}

type HuaweiComputer struct{}
func (h *HuaweiComputer) Play() {
	fmt.Println("this is hua wei play you")
}

type AbstractFactory interface {
	CreatePhone() Phone
	CreateComputer() Computer
}

type XiaomiFactory struct{}
func (xf *XiaomiFactory) CreatePhone() Phone {
	return &MiaomiPhone{}
}
func (xf *XiaomiFactory) CreateComputer() Computer {
	return &MiaomiComputer{}
}

type HuaweiFactory struct{}
func (hf *HuaweiFactory) CreatePhone() Phone {
	return &HuaweiPhone{}
}
func (hf *HuaweiFactory) CreateComputer() Computer {
	return &HuaweiComputer{}
}

type FactoryProvider struct{}
func (fp *FactoryProvider) GetFactory(name string) AbstractFactory {
	var f AbstractFactory
	if name == "xiaomi" {
		f = &XiaomiFactory{}
	} else if name == "huawei" {
		f = &HuaweiFactory{}
	}
	return f
}

func TestAbstractFactory(*testing.T) {
	fp := &FactoryProvider{}
	xiaomiFactory := fp.GetFactory("xiaomi")
	xiaomiPhone := xiaomiFactory.CreatePhone()
	xiaomiPhone.Call()
}

抽象工厂模式优缺点

• 你可以确保同一工厂生成的产品相互匹配。
• 你可以避免客户端和具体产品代码的耦合。
• 单一职责原则。你可以将产品生成代码抽取到同一位置，使得代码易于维护。
• 开闭原则。向应用程序中引入新产品变体时，你无需修改客户端代码。

• 由于采用该模式需要向应用中引入众多接口和类，代码可能会比之前更加复杂。

与其他模式的关系

• 在许多设计工作的初期都会使用工厂方法模式 （较为简单，而且可以更方便地通过子类进行定制），随后演化为使用抽象工厂模式、 原型模式或生成器模式 （更灵活但更加复杂）。
• 生成器重点关注如何分步生成复杂对象。抽象工厂专门用于生产一系列相关对象。抽象工厂会马上返回产品，生成器则允许你在获取产品前执行一些额外构造步骤。
• 抽象工厂模式通常基于一组工厂方法，但你也可以使用原型模式来生成这些类的方法。
• 当只需对客户端代码隐藏子系统创建对象的方式时，你可以使用抽象工厂来代替外观模式。
• 你可以将抽象工厂和桥接模式搭配使用。如果由桥接定义的抽象只能与特定实现合作，这一模式搭配就非常有用。在这种情况下，抽象工厂可以对这些关系进行封装，并且对客户端代码隐藏其复杂性。
• 抽象工厂、 生成器和原型都可以用单例模式来实现。

单例模式Singleton

单例模式是一种创建型设计模式，让你能够保证一个类只有一个实例，并提供一个访问该实例的全局节点。

为什么使用单例模式

单例模式同时解决了两个问题，所以违反了_单一职责原则_：

1. 保证一个类只有一个实例。为什么会有人想要控制一个类所拥有的实例数量？ 最常见的原因是控制某些共享资源 （例如数据库或文件） 的访问权限。

   它的运作方式是这样的： 如果你创建了一个对象，同时过一会儿后你决定再创建一个新对象，此时你会获得之前已创建的对象，而不是一个新对象。

   注意，普通构造函数无法实现上述行为，因为构造函数的设计决定了它必须总是返回一个新对象。

2. 为该实例提供一个全局访问节点。还记得你用过的那些存储重要对象的全局变量吗？ 它们在使用上十分方便，但同时也非常不安全，因为任何代码都有可能覆盖掉那些变量的内容，从而引发程序崩溃。

   和全局变量一样，单例模式也允许在程序的任何地方访问特定对象。但是它可以保护该实例不被其他代码覆盖。

   还有一点： 你不会希望解决同一个问题的代码分散在程序各处的。因此更好的方式是将其放在同一个类中，特别是当其他代码已经依赖这个类时更应该如此。

如今，单例模式已经变得非常流行，以至于人们会将只解决上文描述中任意一个问题的东西称为单例。

解决方案

所有单例的实现都包含以下两个相同的步骤：

• 将默认构造函数设为私有，防止其他对象使用单例类的 new运算符。
• 新建一个静态构建方法作为构造函数。该函数会 “偷偷” 调用私有构造函数来创建对象，并将其保存在一个静态成员变量中。此后所有对于该函数的调用都将返回这一缓存对象。

如果你的代码能够访问单例类，那它就能调用单例类的静态方法。无论何时调用该方法，它总是会返回相同的对象。

单例模式结构

单例模式适合应用场景

• 如果程序中的某个类对于所有客户端只有一个可用的实例，可以使用单例模式。

  单例模式禁止通过除特殊构建方法以外的任何方式来创建自身类的对象。该方法可以创建一个新对象，但如果该对象已经被创建，则返回已有的对象。

• 如果你需要更加严格地控制全局变量，可以使用单例模式。

  单例模式与全局变量不同，它保证类只存在一个实例。除了单例类自己以外，无法通过任何方式替换缓存的实例。

请注意，你可以随时调整限制并设定生成单例实例的数量，只需修改 获取实例方法，即 getInstance 中的代码即可实现。

实现方式

1. 在类中添加一个私有静态成员变量用于保存单例实例。
2. 声明一个公有静态构建方法用于获取单例实例。
3. 在静态方法中实现”延迟初始化”。该方法会在首次被调用时创建一个新对象，并将其存储在静态成员变量中。此后该方法每次被调用时都返回该实例。
4. 将类的构造函数设为私有。类的静态方法仍能调用构造函数，但是其他对象不能调用。
5. 检查客户端代码，将对单例的构造函数的调用替换为对其静态构建方法的调用。

代码实现

package main

import (
    "fmt"
    "sync"
)

var lock = &sync.Mutex{}

type single struct {}

var singleInstance *single

func getInstance() *single {
    if singleInstance == nil {
        lock.Lock()
        defer lock.Unlock()
        if singleInstance == nil {
            fmt.Println("Creating single instance now.")
            singleInstance = &single{}
        } else {
            fmt.Println("Single instance already created.")
        }
    } else {
        fmt.Println("Single instance already created.")
    }

    return singleInstance
}

func main() {
    for i := 0; i < 30; i++ {
        go getInstance()
    }

    // Scanln is similar to Scan, but stops scanning at a newline and
    // after the final item there must be a newline or EOF.
    fmt.Scanln()
}

单例模式优缺点

• 你可以保证一个类只有一个实例。
• 你获得了一个指向该实例的全局访问节点。
• 仅在首次请求单例对象时对其进行初始化。

• 违反了_单一职责原则_。该模式同时解决了两个问题。
• 单例模式可能掩盖不良设计，比如程序各组件之间相互了解过多等。
• 该模式在多线程环境下需要进行特殊处理，避免多个线程多次创建单例对象。
• 单例的客户端代码单元测试可能会比较困难，因为许多测试框架以基于继承的方式创建模拟对象。由于单例类的构造函数是私有的，而且绝大部分语言无法重写静态方法，所以你需要想出仔细考虑模拟单例的方法。要么干脆不编写测试代码，或者不使用单例模式。

与其他模式的关系

• 外观模式类通常可以转换为单例模式类，因为在大部分情况下一个外观对象就足够了。
• 如果你能将对象的所有共享状态简化为一个享元对象，那么享元模式就和单例类似了。但这两个模式有两个根本性的不同。
  1. 只会有一个单例实体，但是享元类可以有多个实体，各实体的内在状态也可以不同。
  2. 单例对象可以是可变的。享元对象是不可变的。
• 抽象工厂模式、 生成器模式和原型模式都可以用单例来实现。

命令模式Command

命令模式是一种行为设计模式，它可将请求转换为一个包含与请求相关的所有信息的独立对象。该转换让你能根据不同的请求将方法参数化、 延迟请求执行或将其放入队列中，且能实现可撤销操作。

为什么使用命令模式

将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化，对请求排队或记录请求日志，以及支持可撤销的操作。

一个请求指的是来自客户端的一个操作，比如菜单按钮点击。重点在点击后并不直接实现，而是将请求封装为一个对象，可以理解为从直接实现：

function onClick() {
  // ... balabala 实现逻辑
}

改为生成一个对象，序列化这个请求：

function onClick() {
  concreteCommand.push({
    // ... 描述这个请求
  })
  // 执行所有命令队列
  concreteCommand.executeAll()
}

看上去繁琐了一些，但得到了后面所说的好处：“从而使你可用不同的请求对客户进行参数化”，也就是可以对任何请求进行参数化存储，我们可以在任意时刻调用。 这相当于掌握了执行时机，可以在任意时刻调用，以实现排队或记录日志，如果再记录下反向操作信息，就可以实现撤销重做了。

• 点菜是命令模式
  为什么顾客会找服务员点菜，而不是直接冲到后厨盯着厨师做菜？因为做菜比较慢，肯定会出现排队的现象，而且有些菜可能是一起做效率更高，所以将点菜和做菜分离比较容易控制整体效率。

  其实这个社会现象就对应编程领域的命令模式：点菜就是一个个请求，点菜员记录的菜单就是将请求生成的对象，点菜员不需要关心怎么做菜、谁来做，他只要把菜单传到后厨即可，由后厨统一调度。

• 大型软件系统的操作菜单

  大型软件操作系统都有一个特点，即软件非常复杂，菜单按钮非常多。但由于菜单按钮本身并没有业务逻辑，所以通过菜单按钮点击后触发的业务行为不适合由菜单按钮完成，此时可利用命令模式生成一个或一系列指令，由软件系统的实现部分来真正执行。

• 浏览器请求排队

  浏览器的请求不仅会排队，还会取消、重试，因此是个典型的命令模式场景。如果不能将 window.fetch 序列化为一个个指令放入到队列中，是无法实现请求排队、取消、重试的。

解决方案

优秀的软件设计通常会将关注点进行分离，而这往往会导致软件的分层。最常见的例子： 一层负责用户图像界面； 另一层负责业务逻辑。GUI 层负责在屏幕上渲染美观的图形，捕获所有输入并显示用户和程序工作的结果。当需要完成一些重要内容时 （比如计算月球轨道或撰写年度报告），GUI 层则会将工作委派给业务逻辑底层。

这在代码中看上去就像这样： 一个 GUI 对象传递一些参数来调用一个业务逻辑对象。这个过程通常被描述为一个对象发送请求给另一个对象。

GUI 层可以直接访问业务逻辑层。

命令模式建议 GUI 对象不直接提交这些请求。你应该将请求的所有细节 （例如调用的对象、 方法名称和参数列表） 抽取出来组成命令类，该类中仅包含一个用于触发请求的方法。

命令对象负责连接不同的 GUI 和业务逻辑对象。此后，GUI 对象无需了解业务逻辑对象是否获得了请求，也无需了解其对请求进行处理的方式。GUI 对象触发命令即可，命令对象会自行处理所有细节工作。

通过命令访问业务逻辑层。

下一步是让所有命令实现相同的接口。该接口通常只有一个没有任何参数的执行方法，让你能在不和具体命令类耦合的情况下使用同一请求发送者执行不同命令。此外还有额外的好处，现在你能在运行时切换连接至发送者的命令对象，以此改变发送者的行为。

你可能会注意到遗漏的一块拼图——请求的参数。GUI 对象可以给业务层对象提供一些参数。但执行命令方法没有任何参数，所以我们如何将请求的详情发送给接收者呢？ 答案是： 使用数据对命令进行预先配置，或者让其能够自行获取数据。

GUI 对象将命令委派给命令对象。

让我们回到文本编辑器。应用命令模式后，我们不再需要任何按钮子类来实现点击行为。我们只需在 按钮Button基类中添加一个成员变量来存储对于命令对象的引用，并在点击后执行该命令即可。

你需要为每个可能的操作实现一系列命令类，并且根据按钮所需行为将命令和按钮连接起来。

其他菜单、 快捷方式或整个对话框等 GUI 元素都可以通过相同方式来实现。当用户与 GUI 元素交互时，与其连接的命令将会被执行。现在你很可能已经猜到了，与相同操作相关的元素将会被连接到相同的命令，从而避免了重复代码。

最后，命令成为了减少 GUI 和业务逻辑层之间耦合的中间层。而这仅仅是命令模式所提供的一小部分好处！

命令模式结构

命令模式适合应用场景

• 如果你需要通过操作来参数化对象，可使用命令模式。

  命令模式可将特定的方法调用转化为独立对象。这一改变也带来了许多有趣的应用： 你可以将命令作为方法的参数进行传递、 将命令保存在其他对象中，或者在运行时切换已连接的命令等。

  举个例子： 你正在开发一个 GUI 组件 （例如上下文菜单），你希望用户能够配置菜单项，并在点击菜单项时触发操作。

• 如果你想要将操作放入队列中、 操作的执行或者远程执行操作，可使用命令模式。

  同其他对象一样，命令也可以实现序列化 （序列化的意思是转化为字符串），从而能方便地写入文件或数据库中。一段时间后，该字符串可被恢复成为最初的命令对象。因此，你可以延迟或计划命令的执行。但其功能远不止如此！ 使用同样的方式，你还可以将命令放入队列、 记录命令或者通过网络发送命令。

• 如果你想要实现操作回滚功能，可使用命令模式。

  尽管有很多方法可以实现撤销和恢复功能，但命令模式可能是其中最常用的一种。

  为了能够回滚操作，你需要实现已执行操作的历史记录功能。命令历史记录是一种包含所有已执行命令对象及其相关程序状态备份的栈结构。

  这种方法有两个缺点。首先，程序状态的保存功能并不容易实现，因为部分状态可能是私有的。你可以使用备忘录模式来在一定程度上解决这个问题。

  其次，备份状态可能会占用大量内存。因此，有时你需要借助另一种实现方式： 命令无需恢复原始状态，而是执行反向操作。反向操作也有代价： 它可能会很难甚至是无法实现。

实现方式

1. 声明仅有一个执行方法的命令接口。
2. 抽取请求并使之成为实现命令接口的具体命令类。每个类都必须有一组成员变量来保存请求参数和对于实际接收者对象的引用。所有这些变量的数值都必须通过命令构造函数进行初始化。
3. 找到担任发送者职责的类。在这些类中添加保存命令的成员变量。发送者只能通过命令接口与其命令进行交互。发送者自身通常并不创建命令对象，而是通过客户端代码获取。
4. 修改发送者使其执行命令，而非直接将请求发送给接收者。
5. 客户端必须按照以下顺序来初始化对象：
   • 创建接收者。
   • 创建命令，如有需要可将其关联至接收者。
   • 创建发送者并将其与特定命令关联。

代码实现

package pattern_dive

import (
	"fmt"
	"testing"
)

type command interface {
	execute()
}

type button struct {
	command command
}

func (b *button) press() {
	b.command.execute()
}

type onCommand struct {
	device device
}

func (c *onCommand) execute() {
	c.device.on()
}

type offCommand struct {
	device device
}

func (c *offCommand) execute() {
	c.device.off()
}

// 设备
type device interface {
	on()
	off()
}

type tv struct {
	isRunning bool
}

func (t *tv) on() {
	t.isRunning = true
	fmt.Println("Turning tv on")
}

func (t *tv) off() {
	t.isRunning = false
	fmt.Println("Turning tv off")
}

func TestCommand(t *testing.T) {
	// 创建设备
	tv := &tv{}

	// 将设备绑定到命令,将关闭/开启功能委托给设备
	onCommand := &onCommand{device: tv}
	offCommand := &offCommand{device: tv}

	// 将命令绑定到按钮
	onButton := &button{command: onCommand}
	offButton := &button{command: offCommand}
	onButton.press()
	offButton.press()
}

命令模式使用连续委托：

1. 创建设备
2. 将设备绑定到命令
3. 将命令绑定到按钮

press()的逻辑会委托给execute()，execute()的逻辑会委托给on()/off()：press() -> execute() -> on()/off()

命令模式优缺点

• 单一职责原则。你可以解耦触发和执行操作的类。
• 开闭原则。你可以在不修改已有客户端代码的情况下在程序中创建新的命令。
• 你可以实现撤销和恢复功能。
• 你可以实现操作的延迟执行。
• 你可以将一组简单命令组合成一个复杂命令。

• 代码可能会变得更加复杂，因为你在发送者和接收者之间增加了一个全新的层次。

与其他模式的关系

• 责任链模式、 命令模式、 中介者模式和观察者模式用于处理请求发送者和接收者之间的不同连接方式：

  • 责任链按照顺序将请求动态传递给一系列的潜在接收者，直至其中一名接收者对请求进行处理。
  • 命令在发送者和请求者之间建立单向连接。
  • 中介者清除了发送者和请求者之间的直接连接，强制它们通过一个中介对象进行间接沟通。
  • 观察者允许接收者动态地订阅或取消接收请求。

• 责任链的管理者可使用命令模式实现。在这种情况下，你可以对由请求代表的同一个上下文对象执行许多不同的操作。

  还有另外一种实现方式，那就是请求自身就是一个命令对象。在这种情况下，你可以对由一系列不同上下文连接而成的链执行相同的操作。

• 你可以同时使用命令和备忘录模式来实现 “撤销”。在这种情况下，命令用于对目标对象执行各种不同的操作，备忘录用来保存一条命令执行前该对象的状态。

• 命令和策略模式看上去很像，因为两者都能通过某些行为来参数化对象。但是，它们的意图有非常大的不同。

  • 你可以使用命令来将任何操作转换为对象。操作的参数将成为对象的成员变量。你可以通过转换来延迟操作的执行、 将操作放入队列、 保存历史命令或者向远程服务发送命令等。
  • 另一方面，策略通常可用于描述完成某件事的不同方式，让你能够在同一个上下文类中切换算法。

• 原型模式可用于保存命令的历史记录。

• 你可以将访问者模式视为命令模式的加强版本，其对象可对不同类的多种对象执行操作。

迭代器模式Iterator

迭代器模式是一种行为设计模式，让你能在不暴露集合底层表现形式 （列表、 栈和树等） 的情况下遍历集合中所有的元素。

为什么使用迭代器模式

集合是编程中最常使用的数据类型之一。尽管如此，集合只是一组对象的容器而已。

大部分集合使用简单列表存储元素。但有些集合还会使用栈、 树、 图和其他复杂的数据结构。

无论集合的构成方式如何，它都必须提供某种访问元素的方式，便于其他代码使用其中的元素。集合应提供一种能够遍历元素的方式，且保证它不会周而复始地访问同一个元素。

如果你的集合基于列表，那么这项工作听上去仿佛很简单。但如何遍历复杂数据结构 （例如树） 中的元素呢？ 例如，今天你需要使用深度优先算法来遍历树结构，明天可能会需要广度优先算法； 下周则可能会需要其他方式 （比如随机存取树中的元素）。

不断向集合中添加遍历算法会模糊其 “高效存储数据” 的主要职责。此外，有些算法可能是根据特定应用订制的，将其加入泛型集合类中会显得非常奇怪。

另一方面，使用多种集合的客户端代码可能并不关心存储数据的方式。不过由于集合提供不同的元素访问方式，你的代码将不得不与特定集合类进行耦合。

解决方案

迭代器模式的主要思想是将集合的遍历行为抽取为单独的迭代器对象。

迭代器可实现多种遍历算法。多个迭代器对象可同时遍历同一个集合。

除实现自身算法外，迭代器还封装了遍历操作的所有细节，例如当前位置和末尾剩余元素的数量。因此，多个迭代器可以在相互独立的情况下同时访问集合。

迭代器通常会提供一个获取集合元素的基本方法。客户端可不断调用该方法直至它不返回任何内容，这意味着迭代器已经遍历了所有元素。

所有迭代器必须实现相同的接口。这样一来，只要有合适的迭代器，客户端代码就能兼容任何类型的集合或遍历算法。如果你需要采用特殊方式来遍历集合，只需创建一个新的迭代器类即可，无需对集合或客户端进行修改。

迭代器模式结构

迭代器模式适合应用场景

• 当集合背后为复杂的数据结构，且你希望对客户端隐藏其复杂性时（出于使用便利性或安全性的考虑），可以使用迭代器模式。

  迭代器封装了与复杂数据结构进行交互的细节，为客户端提供多个访问集合元素的简单方法。这种方式不仅对客户端来说非常方便，而且能避免客户端在直接与集合交互时执行错误或有害的操作，从而起到保护集合的作用。

• 使用该模式可以减少程序中重复的遍历代码。

  重要迭代算法的代码往往体积非常庞大。 当这些代码被放置在程序业务逻辑中时，它会让原始代码的职责模糊不清，降低其可维护性。因此，将遍历代码移到特定的迭代器中可使程序代码更加精炼和简洁。

• 如果你希望代码能够遍历不同的甚至是无法预知的数据结构，可以使用迭代器模式。

  该模式为集合和迭代器提供了一些通用接口。如果你在代码中使用了这些接口，那么将其他实现了这些接口的集合和迭代器传递给它时，它仍将可以正常运行。

实现方式

1. 声明迭代器接口。该接口必须提供至少一个方法来获取集合中的下个元素。但为了使用方便，你还可以添加一些其他方法，例如获取前一个元素、 记录当前位置和判断迭代是否已结束。
2. 声明集合接口并描述一个获取迭代器的方法。其返回值必须是迭代器接口。如果你计划拥有多组不同的迭代器，则可以声明多个类似的方法。
3. 为希望使用迭代器进行遍历的集合实现具体迭代器类。迭代器对象必须与单个集合实体链接。链接关系通常通过迭代器的构造函数建立。
4. 在你的集合类中实现集合接口。其主要思想是针对特定集合为客户端代码提供创建迭代器的快捷方式。集合对象必须将自身传递给迭代器的构造函数来创建两者之间的链接。
5. 检查客户端代码，使用迭代器替代所有集合遍历代码。每当客户端需要遍历集合元素时都会获取一个新的迭代器。

代码实现

package pattern_dive

import (
	"fmt"
	"testing"
)

type iterator interface {
	hasNext() bool
	getNext() *user
}

type userIterator struct {
	index int
	users []*user
}

func (u *userIterator) hasNext() bool {
	if u.index < len(u.users) {
		return true
	}
	return false

}
func (u *userIterator) getNext() *user {
	if u.hasNext() {
		user := u.users[u.index]
		u.index++
		return user
	}
	return nil
}

type user struct {
	name string
	age  int
}

type collection interface {
	createIterator() iterator
}

type userCollection struct {
	users []*user
}

func (u *userCollection) createIterator() iterator {
	return &userIterator{
		users: u.users,
	}
}
a
func TestIterator(t *testing.T) {
	user1 := &user{
		name: "a",
		age:  30,
	}
	user2 := &user{
		name: "b",
		age:  20,
	}

	userCollection := &userCollection{
		users: []*user{user1, user2},
	}

	iterator := userCollection.createIterator()

	for iterator.hasNext() {
		user := iterator.getNext()
		fmt.Printf("User is %+v\n", user)
	}
}

迭代器模式优缺点

• 单一职责原则。通过将体积庞大的遍历算法代码抽取为独立的类，你可对客户端代码和集合进行整理。
• 开闭原则。你可实现新型的集合和迭代器并将其传递给现有代码，无需修改现有代码。
• 你可以并行遍历同一集合，因为每个迭代器对象都包含其自身的遍历状态。
• 相似的，你可以暂停遍历并在需要时继续。

• 如果你的程序只与简单的集合进行交互，应用该模式可能会矫枉过正。
• 对于某些特殊集合，使用迭代器可能比直接遍历的效率低。

与其他模式的关系

• 你可以使用迭代器模式来遍历组合模式树。
• 你可以同时使用工厂方法模式和迭代器来让子类集合返回不同类型的迭代器，并使得迭代器与集合相匹配。
• 你可以同时使用备忘录模式和迭代器来获取当前迭代器的状态，并且在需要的时候进行回滚。
• 可以同时使用访问者模式和迭代器来遍历复杂数据结构，并对其中的元素执行所需操作，即使这些元素所属的类完全不同。

建造者模式Builder

生成器模式是一种创建型设计模式，使你能够分步骤创建复杂对象。该模式允许你使用相同的创建代码生成不同类型和形式的对象。

为什么使用建造者模式

假设有这样一个复杂对象，在对其进行构造时需要对诸多成员变量和嵌套对象进行繁复的初始化工作。这些初始化代码通常深藏于一个包含众多参数且让人基本看不懂的构造函数中； 甚至还有更糟糕的情况，那就是这些代码散落在客户端代码的多个位置。

如果为每种可能的对象都创建一个子类，这可能会导致程序变得过于复杂。

例如，我们来思考如何创建一个 房屋House对象。建造一栋简单的房屋，首先你需要建造四面墙和地板，安装房门和一套窗户，然后再建造一个屋顶。但是如果你想要一栋更宽敞更明亮的房屋，还要有院子和其他设施 （例如暖气、 排水和供电设备），那又该怎么办呢？

最简单的方法是扩展 房屋基类，然后创建一系列涵盖所有参数组合的子类。但最终你将面对相当数量的子类。任何新增的参数 （例如门廊类型） 都会让这个层次结构更加复杂。

另一种方法则无需生成子类。你可以在 房屋基类中创建一个包括所有可能参数的超级构造函数，并用它来控制房屋对象。这种方法确实可以避免生成子类，但它却会造成另外一个问题。

拥有大量输入参数的构造函数也有缺陷： 这些参数也不是每次都要全部用上的。

通常情况下，绝大部分的参数都没有使用，这使得对于构造函数的调用十分不简洁。例如，只有很少的房子有游泳池，因此与游泳池相关的参数十之八九是毫无用处的。

解决方案

生成器模式建议将对象构造代码从产品类中抽取出来，并将其放在一个名为生成器的独立对象中。

生成器模式让你能够分步骤创建复杂对象。生成器不允许其他对象访问正在创建中的产品。

该模式会将对象构造过程划分为一组步骤，比如 build­Walls创建墙壁和 build­Door创建房门创建房门等。每次创建对象时，你都需要通过生成器对象执行一系列步骤。重点在于你无需调用所有步骤，而只需调用创建特定对象配置所需的那些步骤即可。

当你需要创建不同形式的产品时，其中的一些构造步骤可能需要不同的实现。例如，木屋的房门可能需要使用木头制造，而城堡的房门则必须使用石头制造。

在这种情况下，你可以创建多个不同的生成器，用不同方式实现一组相同的创建步骤。然后你就可以在创建过程中使用这些生成器 （例如按顺序调用多个构造步骤） 来生成不同类型的对象。

不同生成器以不同方式执行相同的任务。

例如，假设第一个建造者使用木头和玻璃制造房屋，第二个建造者使用石头和钢铁，而第三个建造者使用黄金和钻石。在调用同一组步骤后，第一个建造者会给你一栋普通房屋，第二个会给你一座小城堡，而第三个则会给你一座宫殿。但是，只有在调用构造步骤的客户端代码可以通过通用接口与建造者进行交互时，这样的调用才能返回需要的房屋。

你可以进一步将用于创建产品的一系列生成器步骤调用抽取成为单独的主管类。主管类可定义创建步骤的执行顺序，而生成器则提供这些步骤的实现。

主管知道需要哪些创建步骤才能获得可正常使用的产品。

严格来说，你的程序中并不一定需要主管类。客户端代码可直接以特定顺序调用创建步骤。不过，主管类中非常适合放入各种例行构造流程，以便在程序中反复使用。

此外，对于客户端代码来说，主管类完全隐藏了产品构造细节。客户端只需要将一个生成器与主管类关联，然后使用主管类来构造产品，就能从生成器处获得构造结果了。

生成器模式结构

生成器模式适合应用场景

• 使用生成器模式可避免 “重叠构造函数 （telescopic constructor）” 的出现。

  假设你的构造函数中有十个可选参数，那么调用该函数会非常不方便； 因此，你需要重载这个构造函数，新建几个只有较少参数的简化版。但这些构造函数仍需调用主构造函数，传递一些默认数值来替代省略掉的参数。

  class Pizza {
      Pizza(int size) { ... }
      Pizza(int size, boolean cheese) { ... }
      Pizza(int size, boolean cheese, boolean pepperoni) { ... }
      // ...

  只有在 C# 或 Java 等支持方法重载的编程语言中才能写出如此复杂的构造函数。

  生成器模式让你可以分步骤生成对象，而且允许你仅使用必须的步骤。应用该模式后，你再也不需要将几十个参数塞进构造函数里了。

• 当你希望使用代码创建不同形式的产品 （例如石头或木头房屋） 时，可使用生成器模式。

  如果你需要创建的各种形式的产品，它们的制造过程相似且仅有细节上的差异，此时可使用生成器模式。

  基本生成器接口中定义了所有可能的制造步骤，具体生成器将实现这些步骤来制造特定形式的产品。同时，主管类将负责管理制造步骤的顺序。

• 使用生成器构造组合树或其他复杂对象。

  生成器模式让你能分步骤构造产品。你可以延迟执行某些步骤而不会影响最终产品。你甚至可以递归调用这些步骤，这在创建对象树时非常方便。

  生成器在执行制造步骤时，不能对外发布未完成的产品。这可以避免客户端代码获取到不完整结果对象的情况。

实现方法

1. 清晰地定义通用步骤，确保它们可以制造所有形式的产品。否则你将无法进一步实施该模式。

2. 在基本生成器接口中声明这些步骤。

3. 为每个形式的产品创建具体生成器类，并实现其构造步骤。

   不要忘记实现获取构造结果对象的方法。你不能在生成器接口中声明该方法，因为不同生成器构造的产品可能没有公共接口，因此你就不知道该方法返回的对象类型。但是，如果所有产品都位于单一类层次中，你就可以安全地在基本接口中添加获取生成对象的方法。

4. 考虑创建主管类。它可以使用同一生成器对象来封装多种构造产品的方式。

5. 客户端代码会同时创建生成器和主管对象。构造开始前，客户端必须将生成器对象传递给主管对象。通常情况下，客户端只需调用主管类构造函数一次即可。主管类使用生成器对象完成后续所有制造任务。还有另一种方式，那就是客户端可以将生成器对象直接传递给主管类的制造方法。

6. 只有在所有产品都遵循相同接口的情况下，构造结果可以直接通过主管类获取。否则，客户端应当通过生成器获取构造结果。

代码实现

package pattern_dive

import (
	"fmt"
	"testing"
)

type house struct {
	windowType string
	doorType   string
	floor      int
}

type iBuilder interface {
	setWindowType()
	setDoorType()
	setNumFloor()
	getHouse() house
}

type normalBuilder struct {
	windowType string
	doorType   string
	floor      int
}

func newNormalBuilder() *normalBuilder {
	return &normalBuilder{}
}

func (b *normalBuilder) setWindowType() {
	b.windowType = "Wooden Window"
}

func (b *normalBuilder) setDoorType() {
	b.doorType = "Wooden Door"
}

func (b *normalBuilder) setNumFloor() {
	b.floor = 2
}

func (b *normalBuilder) getHouse() house {
	return house{
		doorType:   b.doorType,
		windowType: b.windowType,
		floor:      b.floor,
	}
}

type iglooBuilder struct {
	windowType string
	doorType   string
	floor      int
}

func newIglooBuilder() *iglooBuilder {
	return &iglooBuilder{}
}

func (b *iglooBuilder) setWindowType() {
	b.windowType = "Snow Window"
}

func (b *iglooBuilder) setDoorType() {
	b.doorType = "Snow Door"
}

func (b *iglooBuilder) setNumFloor() {
	b.floor = 1
}

func (b *iglooBuilder) getHouse() house {
	return house{
		doorType:   b.doorType,
		windowType: b.windowType,
		floor:      b.floor,
	}
}

func getBuilder(builderType string) iBuilder {
	if builderType == "normal" {
		return &normalBuilder{}
	}

	if builderType == "igloo" {
		return &iglooBuilder{}
	}
	return nil
}

type director struct {
	builder iBuilder
}

func newDirector(b iBuilder) *director {
	return &director{
		builder: b,
	}
}

func (d *director) setBuilder(b iBuilder) {
	d.builder = b
}

func (d *director) buildHouse() house {
	d.builder.setDoorType()
	d.builder.setWindowType()
	d.builder.setNumFloor()
	return d.builder.getHouse()
}

func TestBuilder(t *testing.T) {
	normalBuilder := getBuilder("normal")
	iglooBuilder := getBuilder("igloo")

	director := newDirector(normalBuilder)
	normalHouse := director.buildHouse()

	fmt.Printf("Normal House Door Type: %s\n", normalHouse.doorType)
	fmt.Printf("Normal House Window Type: %s\n", normalHouse.windowType)
	fmt.Printf("Normal House Num Floor: %d\n", normalHouse.floor)

	director.setBuilder(iglooBuilder)
	iglooHouse := director.buildHouse()

	fmt.Printf("\nIgloo House Door Type: %s\n", iglooHouse.doorType)
	fmt.Printf("Igloo House Window Type: %s\n", iglooHouse.windowType)
	fmt.Printf("Igloo House Num Floor: %d\n", iglooHouse.floor)
}

生成器模式优缺点

• 你可以分步创建对象，暂缓创建步骤或递归运行创建步骤。
• 生成不同形式的产品时，你可以复用相同的制造代码。
• 单一职责原则。你可以将复杂构造代码从产品的业务逻辑中分离出来。

• 由于该模式需要新增多个类，因此代码整体复杂程度会有所增加。

与其他模式的关系

• 在许多设计工作的初期都会使用工厂方法模式 （较为简单，而且可以更方便地通过子类进行定制），随后演化为使用抽象工厂模式、 原型模式或生成器模式 （更灵活但更加复杂）。
• 生成器重点关注如何分步生成复杂对象。抽象工厂专门用于生产一系列相关对象。抽象工厂会马上返回产品，生成器则允许你在获取产品前执行一些额外构造步骤。
• 你可以在创建复杂组合模式树时使用生成器，因为这可使其构造步骤以递归的方式运行。
• 你可以结合使用生成器和桥接模式： 主管类负责抽象工作，各种不同的生成器负责实现工作。
• 抽象工厂、 生成器和原型都可以用单例模式来实现。

原型模式Prototype

原型模式是一种创建型设计模式，使你能够复制已有对象，而又无需使代码依赖它们所属的类。

为什么使用原型模式

如果你有一个对象，并希望生成与其完全相同的一个复制品，你该如何实现呢？ 首先，你必须新建一个属于相同类的对象。然后，你必须遍历原始对象的所有成员变量，并将成员变量值复制到新对象中。

不错！ 但有个小问题。并非所有对象都能通过这种方式进行复制，因为有些对象可能拥有私有成员变量，它们在对象本身以外是不可见的。

“从外部” 复制对象并非总是可行。

直接复制还有另外一个问题。因为你必须知道对象所属的类才能创建复制品，所以代码必须依赖该类。即使你可以接受额外的依赖性，那还有另外一个问题： 有时你只知道对象所实现的接口，而不知道其所属的具体类，比如可向方法的某个参数传入实现了某个接口的任何对象。

解决方案

原型模式将克隆过程委派给被克隆的实际对象。模式为所有支持克隆的对象声明了一个通用接口，该接口让你能够克隆对象，同时又无需将代码和对象所属类耦合。通常情况下，这样的接口中仅包含一个 克隆方法。

所有的类对 克隆方法的实现都非常相似。该方法会创建一个当前类的对象，然后将原始对象所有的成员变量值复制到新建的类中。你甚至可以复制私有成员变量，因为绝大部分编程语言都允许对象访问其同类对象的私有成员变量。

支持克隆的对象即为原型。当你的对象有几十个成员变量和几百种类型时，对其进行克隆甚至可以代替子类的构造。

预生成原型可以代替子类的构造。

其运作方式如下： 创建一系列不同类型的对象并不同的方式对其进行配置。如果所需对象与预先配置的对象相同，那么你只需克隆原型即可，无需新建一个对象。

原型模式结构

基本实现：

原型注册表实现：

原型模式适合应用场景

• 如果你需要复制一些对象，同时又希望代码独立于这些对象所属的具体类，可以使用原型模式。

  这一点考量通常出现在代码需要处理第三方代码通过接口传递过来的对象时。即使不考虑代码耦合的情况，你的代码也不能依赖这些对象所属的具体类，因为你不知道它们的具体信息。

  原型模式为客户端代码提供一个通用接口，客户端代码可通过这一接口与所有实现了克隆的对象进行交互，它也使得客户端代码与其所克隆的对象具体类独立开来。

• 如果子类的区别仅在于其对象的初始化方式，那么你可以使用该模式来减少子类的数量。别人创建这些子类的目的可能是为了创建特定类型的对象。

  在原型模式中，你可以使用一系列预生成的、 各种类型的对象作为原型。

  客户端不必根据需求对子类进行实例化，只需找到合适的原型并对其进行克隆即可。

实现方式

1. 创建原型接口，并在其中声明 克隆方法。如果你已有类层次结构，则只需在其所有类中添加该方法即可。

2. 原型类必须另行定义一个以该类对象为参数的构造函数。构造函数必须复制参数对象中的所有成员变量值到新建实体中。如果你需要修改子类，则必须调用父类构造函数，让父类复制其私有成员变量值。

   如果编程语言不支持方法重载，那么你可能需要定义一个特殊方法来复制对象数据。在构造函数中进行此类处理比较方便，因为它在调用 new运算符后会马上返回结果对象。

3. 克隆方法通常只有一行代码： 使用 new运算符调用原型版本的构造函数。注意，每个类都必须显式重写克隆方法并使用自身类名调用 new运算符。否则，克隆方法可能会生成父类的对象。

4. 你还可以创建一个中心化原型注册表，用于存储常用原型。

   你可以新建一个工厂类来实现注册表，或者在原型基类中添加一个获取原型的静态方法。该方法必须能够根据客户端代码设定的条件进行搜索。搜索条件可以是简单的字符串，或者是一组复杂的搜索参数。找到合适的原型后，注册表应对原型进行克隆，并将复制生成的对象返回给客户端。

   最后还要将对子类构造函数的直接调用替换为对原型注册表工厂方法的调用。

代码实现

package pattern_dive

import (
	"fmt"
	"testing"
)

type inode interface {
	print(string)
	clone() inode
}

type file struct {
	name string
}

func (f *file) print(indentation string) {
	fmt.Println(indentation + f.name)
}

func (f *file) clone() inode {
	return &file{name: f.name + "_clone"}
}

type folder struct {
	children []inode
	name     string
}

func (f *folder) print(indentation string) {
	fmt.Println(indentation + f.name)
	for _, i := range f.children {
		i.print(indentation + indentation)
	}
}

func (f *folder) clone() inode {
	cloneFolder := &folder{name: f.name + "_clone"}
	var tempChildren []inode
	for _, i := range f.children {
		copy := i.clone()
		tempChildren = append(tempChildren, copy)
	}
	cloneFolder.children = tempChildren
	return cloneFolder
}

func TestProtoType(t *testing.T) {
	file1 := &file{name: "File1"}
	file2 := &file{name: "File2"}
	file3 := &file{name: "File3"}

	folder1 := &folder{
		children: []inode{file1},
		name:     "Folder1",
	}

	folder2 := &folder{
		children: []inode{folder1, file2, file3},
		name:     "Folder2",
	}
	fmt.Println("\nPrinting hierarchy for Folder2")
	folder2.print("  ")

	cloneFolder := folder2.clone()
	fmt.Println("\nPrinting hierarchy for clone Folder")
	cloneFolder.print("  ")
}

原型模式优缺点

• 你可以克隆对象，而无需与它们所属的具体类相耦合。
• 你可以克隆预生成原型，避免反复运行初始化代码。
• 你可以更方便地生成复杂对象。
• 你可以用继承以外的方式来处理复杂对象的不同配置。

• 克隆包含循环引用的复杂对象可能会非常麻烦。

与其他模式的关系

• 在许多设计工作的初期都会使用工厂方法模式 （较为简单，而且可以更方便地通过子类进行定制），随后演化为使用抽象工厂模式、 原型模式或生成器模式 （更灵活但更加复杂）。
• 抽象工厂模式通常基于一组工厂方法，但你也可以使用原型模式来生成这些类的方法。
• 原型可用于保存命令模式的历史记录。
• 大量使用组合模式和装饰模式的设计通常可从对于原型的使用中获益。你可以通过该模式来复制复杂结构，而非从零开始重新构造。
• 原型并不基于继承，因此没有继承的缺点。另一方面，原型需要对被复制对象进行复杂的初始化。工厂方法基于继承，但是它不需要初始化步骤。
• 有时候原型可以作为备忘录模式的一个简化版本，其条件是你需要在历史记录中存储的对象的状态比较简单，不需要链接其他外部资源，或者链接可以方便地重建。
• 抽象工厂、 生成器和原型都可以用单例模式来实现。

适配器模式Adapter

适配器模式是一种结构型设计模式，它能使接口不兼容的对象能够相互合作。

为什么使用适配器模式

假如你正在开发一款股票市场监测程序，它会从不同来源下载 XML 格式的股票数据，然后向用户呈现出美观的图表。

在开发过程中，你决定在程序中整合一个第三方智能分析函数库。但是遇到了一个问题，那就是分析函数库只兼容 JSON 格式的数据。

你无法 “直接” 使用分析函数库，因为它所需的输入数据格式与你的程序不兼容。

你可以修改程序库来支持 XML。但是，这可能需要修改部分依赖该程序库的现有代码。甚至还有更糟糕的情况，你可能根本没有程序库的源代码，从而无法对其进行修改。

解决方案

你可以创建一个适配器。这是一个特殊的对象，能够转换对象接口，使其能与其他对象进行交互。

适配器模式通过封装对象将复杂的转换过程隐藏于幕后。被封装的对象甚至察觉不到适配器的存在。例如，你可以使用一个将所有数据转换为英制单位 （如英尺和英里） 的适配器封装运行于米和千米单位制中的对象。

适配器不仅可以转换不同格式的数据，其还有助于采用不同接口的对象之间的合作。它的运作方式如下：

1. 适配器实现与其中一个现有对象兼容的接口。
2. 现有对象可以使用该接口安全地调用适配器方法。
3. 适配器方法被调用后将以另一个对象兼容的格式和顺序将请求传递给该对象。

有时你甚至可以创建一个双向适配器来实现双向转换调用。

让我们回到股票市场程序。为了解决数据格式不兼容的问题，你可以为分析函数库中的每个类创建将 XML 转换为 JSON 格式的适配器，然后让客户端仅通过这些适配器来与函数库进行交流。当某个适配器被调用时，它会将传入的 XML 数据转换为 JSON 结构，并将其传递给被封装分析对象的相应方法。

适配器模式结构

对象适配器：实现时使用了构成原则： 适配器实现了其中一个对象的接口，并对另一个对象进行封装。所有流行的编程语言都可以实现适配器。

类适配器：这一实现使用了继承机制： 适配器同时继承两个对象的接口。请注意，这种方式仅能在支持多重继承的编程语言中实现，例如 C++。

适配器模式适合应用场景

• 当你希望使用某个类，但是其接口与其他代码不兼容时，可以使用适配器类。

  适配器模式允许你创建一个中间层类，其可作为代码与遗留类、 第三方类或提供怪异接口的类之间的转换器。

• 如果您需要复用这样一些类，他们处于同一个继承体系，并且他们又有了额外的一些共同的方法，但是这些共同的方法不是所有在这一继承体系中的子类所具有的共性。

  你可以扩展每个子类，将缺少的功能添加到新的子类中。但是，你必须在所有新子类中重复添加这些代码，这样会使得代码有坏味道。

  将缺失功能添加到一个适配器类中是一种优雅得多的解决方案。然后你可以将缺少功能的对象封装在适配器中，从而动态地获取所需功能。如要这一点正常运作，目标类必须要有通用接口，适配器的成员变量应当遵循该通用接口。这种方式同装饰模式非常相似。

实现方式

1. 确保至少有两个类的接口不兼容：
   • 一个无法修改 （通常是第三方、 遗留系统或者存在众多已有依赖的类） 的功能性服务类。
   • 一个或多个将受益于使用服务类的客户端类。
2. 声明客户端接口，描述客户端如何与服务交互。
3. 创建遵循客户端接口的适配器类。所有方法暂时都为空。
4. 在适配器类中添加一个成员变量用于保存对于服务对象的引用。通常情况下会通过构造函数对该成员变量进行初始化，但有时在调用其方法时将该变量传递给适配器会更方便。
5. 依次实现适配器类客户端接口的所有方法。适配器会将实际工作委派给服务对象，自身只负责接口或数据格式的转换。
6. 客户端必须通过客户端接口使用适配器。这样一来，你就可以在不影响客户端代码的情况下修改或扩展适配器。

代码实现

package pattern_dive

import (
	"fmt"
	"testing"
)

type computer interface {
	insertIntoLightningPort()
}

type mac struct{}
func (m *mac) insertIntoLightningPort() {
	fmt.Println("Lightning connector is plugged into mac machine.")
}

type windows struct{}
func (w *windows) insertIntoUSBPort() {
	fmt.Println("USB connector is plugged into windows machine.")
}

type client struct{}
func (c *client) insertLightningConnectorIntoComputer(com computer) {
	fmt.Println("Client inserts Lightning connector into computer.")
	com.insertIntoLightningPort()
}

type windowsAdapter struct {
	windowMachine *windows
}

func (w *windowsAdapter) insertIntoLightningPort() {
	fmt.Println("Adapter converts Lightning signal to USB.")
	w.windowMachine.insertIntoUSBPort()
}

func TestAdapter(t *testing.T) {
	client := &client{}
	mac := &mac{}

	client.insertLightningConnectorIntoComputer(mac)

	windowsMachine := &windows{}
	windowsMachineAdapter := &windowsAdapter{
		windowMachine: windowsMachine,
	}

	client.insertLightningConnectorIntoComputer(windowsMachineAdapter)
}

适配器模式优缺点

• _单一职责原则_你可以将接口或数据转换代码从程序主要业务逻辑中分离。

• 开闭原则。只要客户端代码通过客户端接口与适配器进行交互，你就能在不修改现有客户端代码的情况下在程序中添加新类型的适配器。

• 代码整体复杂度增加，因为你需要新增一系列接口和类。有时直接更改服务类使其与其他代码兼容会更简单。

与其他模式的关系

• 桥接模式通常会于开发前期进行设计，使你能够将程序的各个部分独立开来以便开发。另一方面，适配器模式通常在已有程序中使用，让相互不兼容的类能很好地合作。
• 适配器可以对已有对象的接口进行修改，装饰模式则能在不改变对象接口的前提下强化对象功能。此外，装饰还支持递归组合，适配器则无法实现。
• 适配器能为被封装对象提供不同的接口，代理模式能为对象提供相同的接口，装饰则能为对象提供加强的接口。
• 外观模式为现有对象定义了一个新接口，适配器则会试图运用已有的接口。适配器通常只封装一个对象，外观通常会作用于整个对象子系统上。
• 桥接、 状态模式和策略模式 （在某种程度上包括适配器） 模式的接口非常相似。实际上，它们都基于组合模式——即将工作委派给其他对象，不过也各自解决了不同的问题。模式并不只是以特定方式组织代码的配方，你还可以使用它们来和其他开发者讨论模式所解决的问题。

桥接模式Bridge

桥接模式是一种结构型设计模式，可将一个大类或一系列紧密相关的类拆分为抽象和实现两个独立的层次结构，从而能在开发时分别使用。

为什么使用桥接模式

抽象？ 实现？ 听上去挺吓人？ 让我们慢慢来，先考虑一个简单的例子。

假如你有一个几何 形状Shape类，从它能扩展出两个子类： 圆形Circle和 方形Square 。你希望对这样的类层次结构进行扩展以使其包含颜色，所以你打算创建名为 红色Red和 蓝色Blue的形状子类。但是，由于你已有两个子类，所以总共需要创建四个类才能覆盖所有组合，例如 蓝色圆形Blue­Circle和 红色方形Red­Square 。

所有组合类的数量将以几何级数增长。

在层次结构中新增形状和颜色将导致代码复杂程度指数增长。例如添加三角形状，你需要新增两个子类，也就是每种颜色一个； 此后新增一种新颜色需要新增三个子类，即每种形状一个。如此以往，情况会越来越糟糕。

解决方案

问题的根本原因是我们试图在两个独立的维度——形状与颜色——上扩展形状类。这在处理类继承时是很常见的问题。

桥接模式通过将继承改为组合的方式来解决这个问题。具体来说，就是抽取其中一个维度并使之成为独立的类层次，这样就可以在初始类中引用这个新层次的对象，从而使得一个类不必拥有所有的状态和行为。

将一个类层次转化为多个相关的类层次，避免单个类层次的失控。

根据该方法，我们可以将颜色相关的代码抽取到拥有 红色和 蓝色两个子类的颜色类中，然后在 形状类中添加一个指向某一颜色对象的引用成员变量。现在，形状类可以将所有与颜色相关的工作委派给连入的颜色对象。这样的引用就成为了 形状和 颜色之间的桥梁。此后，新增颜色将不再需要修改形状的类层次，反之亦然。

抽象部分和实现部分：

设计模式四人组的著作 在桥接定义中提出了抽象部分和实现部分两个术语。我觉得这些术语过于学术了，反而让模式看上去比实际情况更加复杂。在介绍过形状和颜色的简单例子后，我们来看看四人组著作中让人望而生畏的词语的含义。

抽象部分 （也被称为接口） 是一些实体的高阶控制层。该层自身不完成任何具体的工作，它需要将工作委派给实现部分层 （也被称为平台）。

注意，这里提到的内容与编程语言中的接口或抽象类无关。它们并不是一回事。

在实际的程序中，抽象部分是图形用户界面 （GUI），而实现部分则是底层操作系统代码 （API），GUI 层调用 API 层来对用户的各种操作做出响应。

一般来说，你可以在两个独立方向上扩展这种应用：

• 开发多个不同的 GUI （例如面向普通用户和管理员进行分别配置）
• 支持多个不同的 API （例如，能够在 Windows、 Linux 和 macOS 上运行该程序）。

在最糟糕的情况下，程序可能会是一团乱麻，其中包含数百种条件语句，连接着代码各处不同种类的 GUI 和各种 API。

在庞杂的代码中，即使是很小的改动都非常难以完成，因为你必须要在整体上对代码有充分的理解。而在较小且定义明确的模块中，进行修改则要容易得多。

你可以将特定接口-平台的组合代码抽取到独立的类中，以在混乱中建立一些秩序。但是，你很快会发现这种类的数量很多。类层次将以指数形式增长，因为每次添加一个新的 GUI 或支持一种新的 API 都需要创建更多的类。

让我们试着用桥接模式来解决这个问题。该模式建议将类拆分为两个类层次结构：

• 抽象部分： 程序的 GUI 层。
• 实现部分： 操作系统的 API。

创建跨平台应用程序的一种方法

抽象对象控制程序的外观，并将真实工作委派给连入的实现对象。不同的实现只要遵循相同的接口就可以互换，使同一 GUI 可在 Windows 和 Linux 下运行。

最后的结果是： 你无需改动与 API 相关的类就可以修改 GUI 类。此外如果想支持一个新的操作系统，只需在实现部分层次中创建一个子类即可。

桥接模式结构

桥接模式适合应用场景

• 如果你想要拆分或重组一个具有多重功能的庞杂类 （例如能与多个数据库服务器进行交互的类），可以使用桥接模式。

  类的代码行数越多，弄清其运作方式就越困难，对其进行修改所花费的时间就越长。一个功能上的变化可能需要在整个类范围内进行修改，而且常常会产生错误，甚至还会有一些严重的副作用。

  桥接模式可以将庞杂类拆分为几个类层次结构。此后，你可以修改任意一个类层次结构而不会影响到其他类层次结构。这种方法可以简化代码的维护工作，并将修改已有代码的风险降到最低。

• 如果你希望在几个独立维度上扩展一个类，可使用该模式。

  桥接建议将每个维度抽取为独立的类层次。初始类将相关工作委派给属于对应类层次的对象，无需自己完成所有工作。

• 如果你需要在运行时切换不同实现方法，可使用桥接模式。

  当然并不是说一定要实现这一点，桥接模式可替换抽象部分中的实现对象，具体操作就和给成员变量赋新值一样简单。

  顺便提一句，最后一点是很多人混淆桥接模式和策略模式的主要原因。记住，设计模式并不仅是一种对类进行组织的方式，它还能用于沟通意图和解决问题。

实现方式

1. 明确类中独立的维度。独立的概念可能是： 抽象/平台，域/基础设施，前端/后端或接口/实现。
2. 了解客户端的业务需求，并在抽象基类中定义它们。
3. 确定在所有平台上都可执行的业务。并在通用实现接口中声明抽象部分所需的业务。
4. 为你域内的所有平台创建实现类，但需确保它们遵循实现部分的接口。
5. 在抽象类中添加指向实现类型的引用成员变量。抽象部分会将大部分工作委派给该成员变量所指向的实现对象。
6. 如果你的高层逻辑有多个变体，则可通过扩展抽象基类为每个变体创建一个精确抽象。
7. 客户端代码必须将实现对象传递给抽象部分的构造函数才能使其能够相互关联。此后，客户端只需与抽象对象进行交互，无需和实现对象打交道。

代码实现

package pattern_dive

import (
	"fmt"
	"testing"
)

// 打印机的打印文件接口
type printer interface {
	printFile()
}

type epson struct {}
func (p *epson) printFile() {
	fmt.Println("Printing by a EPSON Printer")
}

type hp struct {}
func (p *hp) printFile() {
	fmt.Println("Printing by a HP Printer")
}

type computer interface {
	print()
	setPrinter(printer)
}

type mac struct {
	printer printer
}
func (m *mac) print() {
	fmt.Println("Print request for mac")
	m.printer.printFile()
}
func (m *mac) setPrinter(p printer) {
	m.printer = p
}

type windows struct {
	printer printer
}
func (w *windows) print() {
	fmt.Println("Print request for windows")
	w.printer.printFile()
}
func (w *windows) setPrinter(p printer) {
	w.printer = p
}

func TestBridge(t *testing.T) {
	hpPrinter := &hp{}
	epsonPrinter := &epson{}

	macComputer := &mac{}

	macComputer.setPrinter(hpPrinter)
	macComputer.print()
	fmt.Println()

	macComputer.setPrinter(epsonPrinter)
	macComputer.print()
	fmt.Println()

	winComputer := &windows{}

	winComputer.setPrinter(hpPrinter)
	winComputer.print()
	fmt.Println()

	winComputer.setPrinter(epsonPrinter)
	winComputer.print()
	fmt.Println()
}

桥接模式优缺点

• 你可以创建与平台无关的类和程序。
• 客户端代码仅与高层抽象部分进行互动，不会接触到平台的详细信息。
• 开闭原则。你可以新增抽象部分和实现部分，且它们之间不会相互影响。
• 单一职责原则。抽象部分专注于处理高层逻辑，实现部分处理平台细节。

• 对高内聚的类使用该模式可能会让代码更加复杂。

与其他模式的关系

• 桥接模式通常会于开发前期进行设计，使你能够将程序的各个部分独立开来以便开发。另一方面，适配器模式通常在已有程序中使用，让相互不兼容的类能很好地合作。
• 桥接、 状态模式和策略模式 （在某种程度上包括适配器） 模式的接口非常相似。实际上，它们都基于组合模式——即将工作委派给其他对象，不过也各自解决了不同的问题。模式并不只是以特定方式组织代码的配方，你还可以使用它们来和其他开发者讨论模式所解决的问题。
• 你可以将抽象工厂模式和桥接搭配使用。如果由桥接定义的抽象只能与特定实现合作，这一模式搭配就非常有用。在这种情况下，抽象工厂可以对这些关系进行封装，并且对客户端代码隐藏其复杂性。
• 你可以结合使用生成器模式和桥接模式： 主管类负责抽象工作，各种不同的生成器负责实现工作。

组合模式Composite

组合模式是一种结构型设计模式，你可以使用它将对象组合成树状结构，并且能像使用独立对象一样使用它们。

为什么使用组合模式

如果应用的核心模型能用树状结构表示，在应用中使用组合模式才有价值。

例如，你有两类对象： 产品和 盒子 。一个盒子中可以包含多个 产品或者几个较小的 盒子 。这些小 盒子中同样可以包含一些 产品或更小的 盒子 ，以此类推。

假设你希望在这些类的基础上开发一个定购系统。订单中可以包含无包装的简单产品，也可以包含装满产品的盒子……以及其他盒子。此时你会如何计算每张订单的总价格呢？

订单中可能包括各种产品，这些产品放置在盒子中，然后又被放入一层又一层更大的盒子中。整个结构看上去像是一棵倒过来的树。

你可以尝试直接计算： 打开所有盒子，找到每件产品，然后计算总价。这在真实世界中或许可行，但在程序中，你并不能简单地使用循环语句来完成该工作。你必须事先知道所有 产品和 盒子的类别，所有盒子的嵌套层数以及其他繁杂的细节信息。因此，直接计算极不方便，甚至完全不可行。

解决方案

组合模式建议使用一个通用接口来与 产品和 盒子进行交互，并且在该接口中声明一个计算总价的方法。

那么方法该如何设计呢？ 对于一个产品，该方法直接返回其价格； 对于一个盒子，该方法遍历盒子中的所有项目，询问每个项目的价格，然后返回该盒子的总价格。如果其中某个项目是小一号的盒子，那么当前盒子也会遍历其中的所有项目，以此类推，直到计算出所有内部组成部分的价格。你甚至可以在盒子的最终价格中增加额外费用，作为该盒子的包装费用。

组合模式以递归方式处理对象树中的所有项目

该方式的最大优点在于你无需了解构成树状结构的对象的具体类。你也无需了解对象是简单的产品还是复杂的盒子。你只需调用通用接口以相同的方式对其进行处理即可。当你调用该方法后，对象会将请求沿着树结构传递下去。

组合模式结构

组合模式适合应用场景

• 如果你需要实现树状对象结构，可以使用组合模式。

  组合模式为你提供了两种共享公共接口的基本元素类型： 简单叶节点和复杂容器。容器中可以包含叶节点和其他容器。这使得你可以构建树状嵌套递归对象结构。

• 如果你希望客户端代码以相同方式处理简单和复杂元素，可以使用该模式。

  组合模式中定义的所有元素共用同一个接口。在这一接口的帮助下，客户端不必在意其所使用的对象的具体类。

实现方式

1. 确保应用的核心模型能够以树状结构表示。尝试将其分解为简单元素和容器。记住，容器必须能够同时包含简单元素和其他容器。

2. 声明组件接口及其一系列方法，这些方法对简单和复杂元素都有意义。

3. 创建一个叶节点类表示简单元素。程序中可以有多个不同的叶节点类。

4. 创建一个容器类表示复杂元素。在该类中，创建一个数组成员变量来存储对于其子元素的引用。该数组必须能够同时保存叶节点和容器，因此请确保将其声明为组合接口类型。

   实现组件接口方法时，记住容器应该将大部分工作交给其子元素来完成。

5. 最后，在容器中定义添加和删除子元素的方法。

记住，这些操作可在组件接口中声明。这将会违反_接口隔离原则_，因为叶节点类中的这些方法为空。但是，这可以让客户端无差别地访问所有元素，即使是组成树状结构的元素。

代码实现

package pattern_dive

import (
	"fmt"
	"testing"
)

type component interface {
	search(string)
}

type file struct {
	name string
}
func (f *file) search(keyword string) {
	fmt.Printf("Searching for keyword %s in file %s\n", keyword, f.name)
}
func (f *file) getName() string {
	return f.name
}

type folder struct {
	components []component
	name       string
}
func (f *folder) search(keyword string) {
	fmt.Printf("Serching recursively for keyword %s in folder %s\n", keyword, f.name)
	for _, composite := range f.components {
		composite.search(keyword)
	}
}
func (f *folder) add(c component) {
	f.components = append(f.components, c)
}

func TestComposite(t *testing.T) {
	file1 := &file{name: "File1"}
	file2 := &file{name: "File2"}
	file3 := &file{name: "File3"}

	folder1 := &folder{name: "Folder1"}
	folder1.add(file1)

	folder2 := &folder{name: "Folder2"}
	folder2.add(file2)
	folder2.add(file3)
	folder2.add(folder1)

	folder2.search("rose")
}

组合模式优缺点

• 你可以利用多态和递归机制更方便地使用复杂树结构。
• 开闭原则。无需更改现有代码，你就可以在应用中添加新元素，使其成为对象树的一部分。

• 对于功能差异较大的类，提供公共接口或许会有困难。在特定情况下，你需要过度一般化组件接口，使其变得令人难以理解。

与其他模式的关系

• 桥接模式、 状态模式和策略模式 （在某种程度上包括适配器模式） 模式的接口非常相似。实际上，它们都基于组合模式——即将工作委派给其他对象，不过也各自解决了不同的问题。模式并不只是以特定方式组织代码的配方，你还可以使用它们来和其他开发者讨论模式所解决的问题。

• 你可以在创建复杂组合树时使用生成器模式，因为这可使其构造步骤以递归的方式运行。

• 责任链模式通常和组合模式结合使用。在这种情况下，叶组件接收到请求后，可以将请求沿包含全体父组件的链一直传递至对象树的底部。

• 你可以使用迭代器模式来遍历组合树。

• 你可以使用访问者模式对整个组合树执行操作。

• 你可以使用享元模式实现组合树的共享叶节点以节省内存。

• 组合和装饰模式的结构图很相似，因为两者都依赖递归组合来组织无限数量的对象。

  装饰类似于组合，但其只有一个子组件。此外还有一个明显不同： 装饰为被封装对象添加了额外的职责，组合仅对其子节点的结果进行了 “求和”。

  但是，模式也可以相互合作： 你可以使用装饰来扩展组合树中特定对象的行为。

• 大量使用组合和装饰的设计通常可从对于原型模式的使用中获益。你可以通过该模式来复制复杂结构，而非从零开始重新构造。

外观模式Facade

外观模式是一种结构型设计模式，能为程序库、 框架或其他复杂类提供一个简单的接口。

为什么使用外观模式

假设你必须在代码中使用某个复杂的库或框架中的众多对象。正常情况下，你需要负责所有对象的初始化工作、 管理其依赖关系并按正确的顺序执行方法等。

最终，程序中类的业务逻辑将与第三方类的实现细节紧密耦合，使得理解和维护代码的工作很难进行。

解决方案

外观类为包含许多活动部件的复杂子系统提供一个简单的接口。与直接调用子系统相比，外观提供的功能可能比较有限，但它却包含了客户端真正关心的功能。

如果你的程序需要与包含几十种功能的复杂库整合，但只需使用其中非常少的功能，那么使用外观模式会非常方便，

例如，上传猫咪搞笑短视频到社交媒体网站的应用可能会用到专业的视频转换库，但它只需使用一个包含 encode­(filename, format)方法 （以文件名与文件格式为参数进行编码的方法） 的类即可。在创建这个类并将其连接到视频转换库后，你就拥有了自己的第一个外观。

外观模式结构

外观模式适合应用场景

• 如果你需要一个指向复杂子系统的直接接口，且该接口的功能有限，则可以使用外观模式。

  子系统通常会随着时间的推进变得越来越复杂。即便是应用了设计模式，通常你也会创建更多的类。尽管在多种情形中子系统可能是更灵活或易于复用的，但其所需的配置和样板代码数量将会增长得更快。为了解决这个问题，外观将会提供指向子系统中最常用功能的快捷方式，能够满足客户端的大部分需求。

• 如果需要将子系统组织为多层结构，可以使用外观。

  创建外观来定义子系统中各层次的入口。你可以要求子系统仅使用外观来进行交互，以减少子系统之间的耦合。

  让我们回到视频转换框架的例子。该框架可以拆分为两个层次： 音频相关和视频相关。你可以为每个层次创建一个外观，然后要求各层的类必须通过这些外观进行交互。这种方式看上去与中介者模式非常相似。

实现方式

1. 考虑能否在现有子系统的基础上提供一个更简单的接口。如果该接口能让客户端代码独立于众多子系统类，那么你的方向就是正确的。
2. 在一个新的外观类中声明并实现该接口。外观应将客户端代码的调用重定向到子系统中的相应对象处。如果客户端代码没有对子系统进行初始化，也没有对其后续生命周期进行管理，那么外观必须完成此类工作。
3. 如果要充分发挥这一模式的优势，你必须确保所有客户端代码仅通过外观来与子系统进行交互。此后客户端代码将不会受到任何由子系统代码修改而造成的影响，比如子系统升级后，你只需修改外观中的代码即可。
4. 如果外观变得过于臃肿，你可以考虑将其部分行为抽取为一个新的专用外观类。

代码实现

package pattern_dive

// 人们很容易低估使用信用卡订购披萨时幕后工作的复杂程度。在整个过程中会有不少的子系统发挥作用。
// 下面是其中的一部分：检查账户, 检查安全码, 借记/贷记余额, 账簿录入, 发送消息通知
// 在如此复杂的系统中，很容易就会引发大的问题。这就是为什么我们需要外观模式，
// 让客户端可以使用一个简单的接口来处理众多组件。客户端只需要输入卡片详情、 安全码、 支付金额以及操作类型即可。
// 外观模式会与多种组件进一步地进行沟通，而又不会向客户端暴露其内部的复杂性。

import (
	"fmt"
	"log"
	"testing"
)

type walletFacade struct {
	account      *account
	wallet       *wallet
	securityCode *securityCode
	notification *notification
	ledger       *ledger
}

func newWalletFacade(accountID string, code int) *walletFacade {
	fmt.Println("Starting create account")
	walletFacade := &walletFacade{
		account:      newAccount(accountID),
		securityCode: newSecurityCode(code),
		wallet:       newWallet(),
		notification: &notification{},
		ledger:       &ledger{},
	}
	fmt.Println("Account created")
	return walletFacade
}

func (w *walletFacade) addMoneyToWallet(accountID string, securityCode int, amount int) error {
	fmt.Println("Starting add money to wallet")
	err := w.account.checkAccount(accountID)
	if err != nil {
		return err
	}
	err = w.securityCode.checkCode(securityCode)
	if err != nil {
		return err
	}
	w.wallet.creditBalance(amount)
	w.notification.sendWalletCreditNotification()
	w.ledger.makeEntry(accountID, "credit", amount)
	return nil
}

func (w *walletFacade) deductMoneyFromWallet(accountID string, securityCode int, amount int) error {
	fmt.Println("Starting debit money from wallet")
	err := w.account.checkAccount(accountID)
	if err != nil {
		return err
	}

	err = w.securityCode.checkCode(securityCode)
	if err != nil {
		return err
	}
	err = w.wallet.debitBalance(amount)
	if err != nil {
		return err
	}
	w.notification.sendWalletDebitNotification()
	w.ledger.makeEntry(accountID, "credit", amount)
	return nil
}

type account struct {
	name string
}

func newAccount(accountName string) *account {
	return &account{
		name: accountName,
	}
}

func (a *account) checkAccount(accountName string) error {
	if a.name != accountName {
		return fmt.Errorf("Account Name is incorrect")
	}
	fmt.Println("Account Verified")
	return nil
}

type securityCode struct {
	code int
}

func newSecurityCode(code int) *securityCode {
	return &securityCode{
		code: code,
	}
}

func (s *securityCode) checkCode(incomingCode int) error {
	if s.code != incomingCode {
		return fmt.Errorf("Security Code is incorrect")
	}
	fmt.Println("SecurityCode Verified")
	return nil
}

type wallet struct {
	balance int
}

func newWallet() *wallet {
	return &wallet{
		balance: 0,
	}
}

func (w *wallet) creditBalance(amount int) {
	w.balance += amount
	fmt.Println("Wallet balance added successfully")
	return
}

func (w *wallet) debitBalance(amount int) error {
	if w.balance < amount {
		return fmt.Errorf("Balance is not sufficient")
	}
	fmt.Println("Wallet balance is Sufficient")
	w.balance -= amount
	return nil
}

type ledger struct {}
func (s *ledger) makeEntry(accountID, txnType string, amount int) {
	fmt.Printf("Make ledger entry for accountId %s with txnType %s for amount %d\n", accountID, txnType, amount)
	return
}

type notification struct {}
func (n *notification) sendWalletCreditNotification() {
	fmt.Println("Sending wallet credit notification")
}

func (n *notification) sendWalletDebitNotification() {
	fmt.Println("Sending wallet debit notification")
}

func TestFacade(t *testing.T) {
	// 创建钱包
	walletFacade := newWalletFacade("abc", 1234)
	// 往钱包加钱
	err := walletFacade.addMoneyToWallet("abc", 1234, 10)
	if err != nil {
		log.Fatalf("Error: %s\n", err.Error())
	}
	// 花钱
	err = walletFacade.deductMoneyFromWallet("abc", 1234, 5)
	if err != nil {
		log.Fatalf("Error: %s\n", err.Error())
	}
}

外观模式优缺点

• 你可以让自己的代码独立于复杂子系统。

• 外观可能成为与程序中所有类都耦合的上帝对象。

与其他模式的关系

• 外观模式为现有对象定义了一个新接口，适配器模式则会试图运用已有的接口。适配器通常只封装一个对象，外观通常会作用于整个对象子系统上。
• 当只需对客户端代码隐藏子系统创建对象的方式时，你可以使用抽象工厂模式来代替外观。
• 享元模式展示了如何生成大量的小型对象，外观则展示了如何用一个对象来代表整个子系统。
• 外观和中介者模式的职责类似： 它们都尝试在大量紧密耦合的类中组织起合作。
  • 外观为子系统中的所有对象定义了一个简单接口，但是它不提供任何新功能。子系统本身不会意识到外观的存在。子系统中的对象可以直接进行交流。
  • 中介者将系统中组件的沟通行为中心化。各组件只知道中介者对象，无法直接相互交流。
• 外观类通常可以转换为单例模式类，因为在大部分情况下一个外观对象就足够了。
• 外观与代理模式的相似之处在于它们都缓存了一个复杂实体并自行对其进行初始化。代理与其服务对象遵循同一接口，使得自己和服务对象可以互换，在这一点上它与外观不同。

享元模式

享元模式是一种结构型设计模式，它摒弃了在每个对象中保存所有数据的方式，通过共享多个对象所共有的相同状态，让你能在有限的内存容量中载入更多对象。

为什么使用享元模式

开发了一款简单的游戏： 玩家们在地图上移动并相互射击。你决定实现一个真实的粒子系统，并将其作为游戏的特色。大量的子弹、 导弹和爆炸弹片会在整个地图上穿行，为玩家提供紧张刺激的游戏体验。

开发完成后，你推送提交了最新版本的程序，并在编译游戏后将其发送给了一个朋友进行测试。尽管该游戏在你的电脑上完美运行，但是你的朋友却无法长时间进行游戏： 游戏总是会在他的电脑上运行几分钟后崩溃。在研究了几个小时的调试消息记录后，你发现导致游戏崩溃的原因是内存容量不足。朋友的设备性能远比不上你的电脑，因此游戏运行在他的电脑上时很快就会出现问题。

真正的问题与粒子系统有关。每个粒子 （一颗子弹、 一枚导弹或一块弹片） 都由包含完整数据的独立对象来表示。当玩家在游戏中鏖战进入高潮后的某一时刻，游戏将无法在剩余内存中载入新建粒子，于是程序就崩溃了。

解决方案

仔细观察 粒子Particle类，你可能会注意到颜色 （color） 和精灵图 （sprite）这两个成员变量所消耗的内存要比其他变量多得多。更糟糕的是，对于所有的粒子来说，这两个成员变量所存储的数据几乎完全一样 （比如所有子弹的颜色和精灵图都一样）。

每个粒子的另一些状态 （坐标、 移动矢量和速度） 则是不同的。因为这些成员变量的数值会不断变化。这些数据代表粒子在存续期间不断变化的情景，但每个粒子的颜色和精灵图则会保持不变。

对象的常量数据通常被称为内在状态，其位于对象中，其他对象只能读取但不能修改其数值。而对象的其他状态常常能被其他对象 “从外部” 改变，因此被称为外在状态。

享元模式建议不在对象中存储外在状态，而是将其传递给依赖于它的一个特殊方法。程序只在对象中保存内在状态，以方便在不同情景下重用。这些对象的区别仅在于其内在状态 （与外在状态相比，内在状态的变体要少很多），因此你所需的对象数量会大大削减。

让我们回到游戏中。假如能从粒子类中抽出外在状态，那么我们只需三个不同的对象 （子弹、 导弹和弹片） 就能表示游戏中的所有粒子。你现在很可能已经猜到了，我们将这样一个仅存储内在状态的对象称为享元。

外在状态存储：

那么外在状态会被移动到什么地方呢？ 总得有类来存储它们，对不对？ 在大部分情况中，它们会被移动到容器对象中，也就是我们应用享元模式前的聚合对象中。

在我们的例子中，容器对象就是主要的 游戏Game对象，其会将所有粒子存储在名为 粒子particles的成员变量中。为了能将外在状态移动到这个类中，你需要创建多个数组成员变量来存储每个粒子的坐标、 方向矢量和速度。除此之外，你还需要另一个数组来存储指向代表粒子的特定享元的引用。这些数组必须保持同步，这样你才能够使用同一索引来获取关于某个粒子的所有数据。

更优雅的解决方案是创建独立的情景类来存储外在状态和对享元对象的引用。在该方法中，容器类只需包含一个数组。

稍等！这样的话情景对象数量不是会和不采用该模式时的对象数量一样多吗？ 的确如此，但这些对象要比之前小很多。消耗内存最多的成员变量已经被移动到很少的几个享元对象中了。现在，一个享元大对象会被上千个情境小对象复用，因此无需再重复存储数千个大对象的数据。

享元与不可变性：

由于享元对象可在不同的情景中使用，你必须确保其状态不能被修改。享元类的状态只能由构造函数的参数进行一次性初始化，它不能对其他对象公开其设置器或公有成员变量。

享元工厂：

为了能更方便地访问各种享元，你可以创建一个工厂方法来管理已有享元对象的缓存池。工厂方法从客户端处接收目标享元对象的内在状态作为参数，如果它能在缓存池中找到所需享元，则将其返回给客户端； 如果没有找到，它就会新建一个享元，并将其添加到缓存池中。

你可以选择在程序的不同地方放入该函数。最简单的选择就是将其放置在享元容器中。除此之外，你还可以新建一个工厂类，或者创建一个静态的工厂方法并将其放入实际的享元类中。

享元模式结构

享元模式适合应用场景

• 仅在程序必须支持大量对象且没有足够的内存容量时使用享元模式。

  应用该模式所获的收益大小取决于使用它的方式和情景。它在下列情况中最有效：

  • 程序需要生成数量巨大的相似对象
  • 这将耗尽目标设备的所有内存
  • 对象中包含可抽取且能在多个对象间共享的重复状态。

实现方式

1. 将需要改写为享元的类成员变量拆分为两个部分：
   • 内在状态： 包含不变的、 可在许多对象中重复使用的数据的成员变量。
   • 外在状态： 包含每个对象各自不同的情景数据的成员变量
2. 保留类中表示内在状态的成员变量，并将其属性设置为不可修改。这些变量仅可在构造函数中获得初始数值。
3. 找到所有使用外在状态成员变量的方法，为在方法中所用的每个成员变量新建一个参数，并使用该参数代替成员变量。
4. 你可以有选择地创建工厂类来管理享元缓存池，它负责在新建享元时检查已有的享元。如果选择使用工厂，客户端就只能通过工厂来请求享元，它们需要将享元的内在状态作为参数传递给工厂。
5. 客户端必须存储和计算外在状态 （情景） 的数值，因为只有这样才能调用享元对象的方法。为了使用方便，外在状态和引用享元的成员变量可以移动到单独的情景类中。

代码实现

package pattern_dive

import (
	"fmt"
	"testing"
)

// 在游戏《反恐精英》 中，恐怖分子和反恐精英身着不同类型的衣物。
// 为了简便起见，我们就假设双方都各有一种服装类型。服装对象嵌入在玩家对象之中
type dress interface {
	getColor() string
}

type terroristDress struct {
	color string
}
func (t *terroristDress) getColor() string {
	return t.color
}
func newTerroristDress() *terroristDress {
	return &terroristDress{color: "red"}
}

type counterTerroristDress struct {
	color string
}
func (c *counterTerroristDress) getColor() string {
	return c.color
}
func newCounterTerroristDress() *counterTerroristDress {
	return &counterTerroristDress{color: "green"}
}

const (
	TerroristDressType        = "tDress"
	CounterTerroristDressType = "ctDress"
)

var (
	dressFactorySingleInstance = &dressFactory{
		dressMap: make(map[string]dress),
	}
)

type dressFactory struct {
	dressMap map[string]dress
}

func getDressFactorySingleInstance() *dressFactory {
	return dressFactorySingleInstance
}

func (d *dressFactory) getDressByType(dressType string) (dress, error) {
	if d.dressMap[dressType] != nil {
		return d.dressMap[dressType], nil
	}

	if dressType == TerroristDressType {
		d.dressMap[dressType] = newTerroristDress()
		return d.dressMap[dressType], nil
	}
	if dressType == CounterTerroristDressType {
		d.dressMap[dressType] = newCounterTerroristDress()
		return d.dressMap[dressType], nil
	}

	return nil, fmt.Errorf("Wrong dress type passed")
}

type player struct {
	dress      dress
	playerType string // 可为 T 或 CT
	lat        int
	long       int
}

func newPlayer(playerType, dressType string) *player {
	dress, _ := getDressFactorySingleInstance().getDressByType(dressType)
	return &player{
		playerType: playerType,
		dress:      dress,
	}
}

func (p *player) newLocation(lat, long int) {
	p.lat = lat
	p.long = long
}

type game struct {
	terrorists        []*player
	counterTerrorists []*player
}

func newGame() *game {
	return &game{
		terrorists:        make([]*player, 1),
		counterTerrorists: make([]*player, 1),
	}
}

func (c *game) addTerrorist(dressType string) {
	player := newPlayer("T", dressType)
	c.terrorists = append(c.terrorists, player)
	return
}

func (c *game) addCounterTerrorist(dressType string) {
	player := newPlayer("CT", dressType)
	c.counterTerrorists = append(c.counterTerrorists, player)
	return
}

// 内部状态： 内部状态的服装可在多个恐怖分子和反恐精英对象间共享。
// 外部状态： 玩家位置和玩家所使用的武器就是外部状态，因为其在每个对象中都是不同的。

// 享元模式会从对象中提取出公共部分并创建享元对象。
// 这些享元对象 （服装） 随后可在多个对象 （玩家） 中分享。
// 这极大地减少了服装对象的数量，更棒的是即便你创建了更多玩家，也只需这么两个服装对象就足够了。
// 在享元模式中，我们会将享元对象存储在 map 容器中。
// 每当创建共享享元对象的其他对象时，都会从 map 容器中获取享元对象。
func TestFlyWeight(t *testing.T) {
	game := newGame()

	//Add Terrorist
	game.addTerrorist(TerroristDressType)
	game.addTerrorist(TerroristDressType)
	game.addTerrorist(TerroristDressType)
	game.addTerrorist(TerroristDressType)

	//Add CounterTerrorist
	game.addCounterTerrorist(CounterTerroristDressType)
	game.addCounterTerrorist(CounterTerroristDressType)
	game.addCounterTerrorist(CounterTerroristDressType)

	dressFactoryInstance := getDressFactorySingleInstance()

	for dressType, dress := range dressFactoryInstance.dressMap {
		fmt.Printf("DressColorType: %s\nDressColor: %s\n", dressType, dress.getColor())
	}
}

享元模式优缺点

• 如果程序中有很多相似对象，那么你将可以节省大量内存。

• 你可能需要牺牲执行速度来换取内存，因为他人每次调用享元方法时都需要重新计算部分情景数据。
• 代码会变得更加复杂。团队中的新成员总是会问： “为什么要像这样拆分一个实体的状态？”。

与其他模式的关系

• 你可以使用享元模式实现组合模式树的共享叶节点以节省内存。
• 享元展示了如何生成大量的小型对象，外观模式则展示了如何用一个对象来代表整个子系统。
• 如果你能将对象的所有共享状态简化为一个享元对象，那么享元就和单例模式类似了。但这两个模式有两个根本性的不同。
  1. 只会有一个单例实体，但是享元类可以有多个实体，各实体的内在状态也可以不同。
  2. 单例对象可以是可变的。享元对象是不可变的。

代理模式Proxy

代理模式是一种结构型设计模式，让你能够提供对象的替代品或其占位符。代理控制着对于原对象的访问，并允许在将请求提交给对象前后进行一些处理。

为什么要使用代理模式

为什么要控制对于某个对象的访问呢？ 举个例子： 有这样一个消耗大量系统资源的巨型对象，你只是偶尔需要使用它，并非总是需要。

数据库查询有可能会非常缓慢。

你可以实现延迟初始化： 在实际有需要时再创建该对象。对象的所有客户端都要执行延迟初始代码。不幸的是，这很可能会带来很多重复代码。

在理想情况下，我们希望将代码直接放入对象的类中，但这并非总是能实现： 比如类可能是第三方封闭库的一部分。

解决方案

代理模式建议新建一个与原服务对象接口相同的代理类，然后更新应用以将代理对象传递给所有原始对象客户端。代理类接收到客户端请求后会创建实际的服务对象，并将所有工作委派给它。

代理将自己伪装成数据库对象，可在客户端或实际数据库对象不知情的情况下处理延迟初始化和缓存查询结果的工作。

这有什么好处呢？ 如果需要在类的主要业务逻辑前后执行一些工作，你无需修改类就能完成这项工作。由于代理实现的接口与原类相同，因此你可将其传递给任何一个使用实际服务对象的客户端。

代理模式适合应用场景

使用代理模式的方式多种多样，我们来看看最常见的几种。

• 延迟初始化 （虚拟代理）。如果你有一个偶尔使用的重量级服务对象，一直保持该对象运行会消耗系统资源时，可使用代理模式。

  你无需在程序启动时就创建该对象，可将对象的初始化延迟到真正有需要的时候。

• 访问控制 （保护代理）。如果你只希望特定客户端使用服务对象，这里的对象可以是操作系统中非常重要的部分，而客户端则是各种已启动的程序 （包括恶意程序），此时可使用代理模式。

  代理可仅在客户端凭据满足要求时将请求传递给服务对象。

• 本地执行远程服务 （远程代理）。适用于服务对象位于远程服务器上的情形。

  在这种情形中，代理通过网络传递客户端请求，负责处理所有与网络相关的复杂细节。

• 记录日志请求 （日志记录代理）。适用于当你需要保存对于服务对象的请求历史记录时。代理可以在向服务传递请求前进行记录。

  缓存请求结果 （缓存代理）。适用于需要缓存客户请求结果并对缓存生命周期进行管理时，特别是当返回结果的体积非常大时。

  • 代理可对重复请求所需的相同结果进行缓存，还可使用请求参数作为索引缓存的键值。

• 智能引用。可在没有客户端使用某个重量级对象时立即销毁该对象。

  代理会将所有获取了指向服务对象或其结果的客户端记录在案。代理会时不时地遍历各个客户端，检查它们是否仍在运行。如果相应的客户端列表为空，代理就会销毁该服务对象，释放底层系统资源。

  代理还可以记录客户端是否修改了服务对象。其他客户端还可以复用未修改的对象。

实现方式

1. 如果没有现成的服务接口，你就需要创建一个接口来实现代理和服务对象的可交换性。从服务类中抽取接口并非总是可行的，因为你需要对服务的所有客户端进行修改，让它们使用接口。备选计划是将代理作为服务类的子类，这样代理就能继承服务的所有接口了。
2. 创建代理类，其中必须包含一个存储指向服务的引用的成员变量。通常情况下，代理负责创建服务并对其整个生命周期进行管理。在一些特殊情况下，客户端会通过构造函数将服务传递给代理。
3. 根据需求实现代理方法。在大部分情况下，代理在完成一些任务后应将工作委派给服务对象。
4. 可以考虑新建一个构建方法来判断客户端可获取的是代理还是实际服务。你可以在代理类中创建一个简单的静态方法，也可以创建一个完整的工厂方法。
5. 可以考虑为服务对象实现延迟初始化。

代码实现

package pattern_dive

import (
	"fmt"
	"testing"
)

type server interface {
	handleRequest(string, string) (int, string)
}

type application struct {}
func (a *application) handleRequest(url, method string) (int, string) {
	if url == "/app/status" && method == "GET" {
		return 200, "Ok"
	}

	if url == "/create/user" && method == "POST" {
		return 201, "User Created"
	}
	return 404, "Not Ok"
}

type nginx struct {
	application       *application
	maxAllowedRequest int
	rateLimiter       map[string]int
}

func newNginxServer() *nginx {
	return &nginx{
		application:       &application{},
		maxAllowedRequest: 2,
		rateLimiter:       make(map[string]int),
	}
}

func (n *nginx) handleRequest(url, method string) (int, string) {
	allowed := n.checkRateLimiting(url)
	if !allowed {
		return 403, "Not Allowed"
	}
	return n.application.handleRequest(url, method)
}

func (n *nginx) checkRateLimiting(url string) bool {
	if n.rateLimiter[url] == 0 {
		n.rateLimiter[url] = 1
	}
	if n.rateLimiter[url] > n.maxAllowedRequest {
		return false
	}
	n.rateLimiter[url] = n.rateLimiter[url] + 1
	return true
}

func TestProxy(t *testing.T) {
	nginxServer := newNginxServer()
	appStatusURL := "/app/status"
	createUserURL := "/create/user"

	httpCode, body := nginxServer.handleRequest(appStatusURL, "GET")
	fmt.Printf("\nUrl: %s\nHttpCode: %d\nBody: %s\n", appStatusURL, httpCode, body)

	httpCode, body = nginxServer.handleRequest(appStatusURL, "GET")
	fmt.Printf("\nUrl: %s\nHttpCode: %d\nBody: %s\n", appStatusURL, httpCode, body)

	httpCode, body = nginxServer.handleRequest(appStatusURL, "GET")
	fmt.Printf("\nUrl: %s\nHttpCode: %d\nBody: %s\n", appStatusURL, httpCode, body)

	httpCode, body = nginxServer.handleRequest(createUserURL, "POST")
	fmt.Printf("\nUrl: %s\nHttpCode: %d\nBody: %s\n", appStatusURL, httpCode, body)

	httpCode, body = nginxServer.handleRequest(createUserURL, "GET")
	fmt.Printf("\nUrl: %s\nHttpCode: %d\nBody: %s\n", appStatusURL, httpCode, body)
}

代理模式优缺点

• 你可以在客户端毫无察觉的情况下控制服务对象。

• 如果客户端对服务对象的生命周期没有特殊要求，你可以对生命周期进行管理。

• 即使服务对象还未准备好或不存在，代理也可以正常工作。

• 开闭原则。你可以在不对服务或客户端做出修改的情况下创建新代理。

• 代码可能会变得复杂，因为需要新建许多类。

• 服务响应可能会延迟。

与其他模式的关系

• 适配器模式能为被封装对象提供不同的接口，代理模式能为对象提供相同的接口，装饰模式则能为对象提供加强的接口。
• 外观模式与代理的相似之处在于它们都缓存了一个复杂实体并自行对其进行初始化。代理与其服务对象遵循同一接口，使得自己和服务对象可以互换，在这一点上它与外观不同。
• 装饰和代理有着相似的结构，但是其意图却非常不同。这两个模式的构建都基于组合原则，也就是说一个对象应该将部分工作委派给另一个对象。两者之间的不同之处在于代理通常自行管理其服务对象的生命周期，而装饰的生成则总是由客户端进行控制。

责任链模式Chain of Responsibility

责任链模式是一种行为设计模式，允许你将请求沿着处理者链进行发送。收到请求后，每个处理者均可对请求进行处理，或将其传递给链上的下个处理者。

为什么要使用责任链模式

你正在开发一个在线订购系统。你希望对系统访问进行限制，只允许认证用户创建订单。此外，拥有管理权限的用户也拥有所有订单的完全访问权限。

简单规划后，你会意识到这些检查必须依次进行。只要接收到包含用户凭据的请求，应用程序就可尝试对进入系统的用户进行认证。但如果由于用户凭据不正确而导致认证失败，那就没有必要进行后续检查了。

请求必须经过一系列检查后才能由订购系统来处理。

在接下来的几个月里，你实现了后续的几个检查步骤。

• 一位同事认为直接将原始数据传递给订购系统存在安全隐患。因此你新增了额外的验证步骤来清理请求中的数据。
• 过了一段时间，有人注意到系统无法抵御暴力密码破解方式的攻击。为了防范这种情况，你立刻添加了一个检查步骤来过滤来自同一 IP 地址的重复错误请求。
• 又有人提议你可以对包含同样数据的重复请求返回缓存中的结果，从而提高系统响应速度。因此，你新增了一个检查步骤，确保只有没有满足条件的缓存结果时请求才能通过并被发送给系统。

代码变得越来越多，也越来越混乱。

检查代码本来就已经混乱不堪，而每次新增功能都会使其更加臃肿。修改某个检查步骤有时会影响其他的检查步骤。最糟糕的是，当你希望复用这些检查步骤来保护其他系统组件时，你只能复制部分代码，因为这些组件只需部分而非全部的检查步骤。

系统会变得让人非常费解，而且其维护成本也会激增。你在艰难地和这些代码共处一段时间后，有一天终于决定对整个系统进行重构。

解决方案

与许多其他行为设计模式一样，责任链会将特定行为转换为被称作处理者的独立对象。在上述示例中，每个检查步骤都可被抽取为仅有单个方法的类，并执行检查操作。请求及其数据则会被作为参数传递给该方法。

模式建议你将这些处理者连成一条链。链上的每个处理者都有一个成员变量来保存对于下一处理者的引用。除了处理请求外，处理者还负责沿着链传递请求。请求会在链上移动，直至所有处理者都有机会对其进行处理。

最重要的是： 处理者可以决定不再沿着链传递请求，这可高效地取消所有后续处理步骤。

在我们的订购系统示例中，处理者会在进行请求处理工作后决定是否继续沿着链传递请求。如果请求中包含正确的数据，所有处理者都将执行自己的主要行为，无论该行为是身份验证还是数据缓存。

处理者依次排列，组成一条链。

不过还有一种稍微不同的方式 （也是更经典一种），那就是处理者接收到请求后自行决定是否能够对其进行处理。如果自己能够处理，处理者就不再继续传递请求。因此在这种情况下，每个请求要么最多有一个处理者对其进行处理，要么没有任何处理者对其进行处理。在处理图形用户界面元素栈中的事件时，这种方式非常常见。

例如，当用户点击按钮时，按钮产生的事件将沿着 GUI 元素链进行传递，最开始是按钮的容器 （如窗体或面板），直至应用程序主窗口。链上第一个能处理该事件的元素会对其进行处理。此外，该例还有另一个值得我们关注的地方： 它表明我们总能从对象树中抽取出链来。

对象树的枝干可以组成一条链。

所有处理者类均实现同一接口是关键所在。每个具体处理者仅关心下一个包含 execute执行方法的处理者。这样一来，你就可以在运行时使用不同的处理者来创建链，而无需将相关代码与处理者的具体类进行耦合。

责任链模式结构

责任链模式适合应用场景

• 当程序需要使用不同方式处理不同种类请求，而且请求类型和顺序预先未知时，可以使用责任链模式。

  该模式能将多个处理者连接成一条链。接收到请求后，它会 “询问” 每个处理者是否能够对其进行处理。这样所有处理者都有机会来处理请求。

• 当必须按顺序执行多个处理者时，可以使用该模式。

  无论你以何种顺序将处理者连接成一条链，所有请求都会严格按照顺序通过链上的处理者。

• 如果所需处理者及其顺序必须在运行时进行改变，可以使用责任链模式。

  如果在处理者类中有对引用成员变量的设定方法，你将能动态地插入和移除处理者，或者改变其顺序。

实现方式

1. 声明处理者接口并描述请求处理方法的签名。

   确定客户端如何将请求数据传递给方法。最灵活的方式是将请求转换为对象，然后将其以参数的形式传递给处理函数。

2. 为了在具体处理者中消除重复的样本代码，你可以根据处理者接口创建抽象处理者基类。

   该类需要有一个成员变量来存储指向链上下个处理者的引用。你可以将其设置为不可变类。但如果你打算在运行时对链进行改变，则需要定义一个设定方法来修改引用成员变量的值。

   为了使用方便，你还可以实现处理方法的默认行为。如果还有剩余对象，该方法会将请求传递给下个对象。具体处理者还能够通过调用父对象的方法来使用这一行为。

3. 依次创建具体处理者子类并实现其处理方法。每个处理者在接收到请求后都必须做出两个决定：

   • 是否自行处理这个请求。
   • 是否将该请求沿着链进行传递。

4. 客户端可以自行组装链，或者从其他对象处获得预先组装好的链。在后一种情况下，你必须实现工厂类以根据配置或环境设置来创建链。

5. 客户端可以触发链中的任意处理者，而不仅仅是第一个。请求将通过链进行传递，直至某个处理者拒绝继续传递，或者请求到达链尾。

6. 由于链的动态性，客户端需要准备好处理以下情况：

   • 链中可能只有单个链接。
   • 部分请求可能无法到达链尾。
   • 其他请求可能直到链尾都未被处理。

代码实现

package pattern_dive

import (
	"fmt"
	"testing"
)

type patient struct {
	name              string
	registrationDone  bool  // 完成登记
	doctorCheckUpDone bool  // 医生完成检查
	medicineDone      bool  // 完成取药
	paymentDone       bool  // 完成结账
}

type department interface {
	execute(*patient)
	setNext(department)
}

// 前台
type reception struct {
	next department
}

func (r *reception) execute(p *patient) {
	if p.registrationDone {
		fmt.Println("Patient registration already done")
		r.next.execute(p)
		return
	}
	fmt.Println("Reception registering patient")
	p.registrationDone = true
	r.next.execute(p)
}

func (r *reception) setNext(next department) {
	r.next = next
}

type doctor struct {
	next department
}

func (d *doctor) execute(p *patient) {
	if p.doctorCheckUpDone {
		fmt.Println("Doctor checkup already done")
		d.next.execute(p)
		return
	}
	fmt.Println("Doctor checking patient")
	p.doctorCheckUpDone = true
	d.next.execute(p)
}

func (d *doctor) setNext(next department) {
	d.next = next
}

type medical struct {
	next department
}

func (m *medical) execute(p *patient) {
	if p.medicineDone {
		fmt.Println("Medicine already given to patient")
		m.next.execute(p)
		return
	}
	fmt.Println("Medical giving medicine to patient")
	p.medicineDone = true
	m.next.execute(p)
}

func (m *medical) setNext(next department) {
	m.next = next
}

type cashier struct {
	next department
}

func (c *cashier) execute(p *patient) {
	if p.paymentDone {
		fmt.Println("Payment Done")
	}
	fmt.Println("Cashier getting money from patient patient")
}

func (c *cashier) setNext(next department) {
	c.next = next
}

func TestChainOfResponsibility(t *testing.T) {
	cashier := &cashier{}

	//Set next for medical department
	medical := &medical{}
	medical.setNext(cashier)

	//Set next for doctor department
	doctor := &doctor{}
	doctor.setNext(medical)

	//Set next for reception department
	reception := &reception{}
	reception.setNext(doctor)

	patient := &patient{name: "abc"}
	//Patient visiting
	reception.execute(patient)
}

责任链模式优缺点

• 你可以控制请求处理的顺序。
• 单一职责原则。你可对发起操作和执行操作的类进行解耦。
• 开闭原则。你可以在不更改现有代码的情况下在程序中新增处理者。

• 部分请求可能未被处理。

与其他模式的关系

• 责任链模式、 命令模式、 中介者模式和观察者模式用于处理请求发送者和接收者之间的不同连接方式：

  • 责任链按照顺序将请求动态传递给一系列的潜在接收者，直至其中一名接收者对请求进行处理。
  • 命令在发送者和请求者之间建立单向连接。
  • 中介者清除了发送者和请求者之间的直接连接，强制它们通过一个中介对象进行间接沟通。
  • 观察者允许接收者动态地订阅或取消接收请求。

• 责任链通常和组合模式结合使用。在这种情况下，叶组件接收到请求后，可以将请求沿包含全体父组件的链一直传递至对象树的底部。

• 责任链的管理者可使用命令模式实现。在这种情况下，你可以对由请求代表的同一个上下文对象执行许多不同的操作。

  还有另外一种实现方式，那就是请求自身就是一个命令对象。在这种情况下，你可以对由一系列不同上下文连接而成的链执行相同的操作。

• 责任链和装饰模式的类结构非常相似。两者都依赖递归组合将需要执行的操作传递给一系列对象。但是，两者有几点重要的不同之处。

  责任链的管理者可以相互独立地执行一切操作，还可以随时停止传递请求。另一方面，各种装饰可以在遵循基本接口的情况下扩展对象的行为。此外，装饰无法中断请求的传递。

中介者模式Mediator

中介者模式是一种行为设计模式，能让你减少对象之间混乱无序的依赖关系。该模式会限制对象之间的直接交互，迫使它们通过一个中介者对象进行合作。

为什么使用中介者模式

假如你有一个创建和修改客户资料的对话框，它由各种控件组成，例如文本框 （Text­Field）、 复选框 （Checkbox） 和按钮 （Button） 等。

用户界面中各元素间的关系会随程序发展而变得混乱。

某些表单元素可能会直接进行互动。例如，选中 “我有一只狗” 复选框后可能会显示一个隐藏文本框用于输入狗狗的名字。另一个例子是提交按钮必须在保存数据前校验所有输入内容。

元素间存在许多关联。因此，对某些元素进行修改可能会影响其他元素。

如果直接在表单元素代码中实现业务逻辑，你将很难在程序其他表单中复用这些元素类。例如，由于复选框类与狗狗的文本框相耦合，所以将无法在其他表单中使用它。你要么使用渲染资料表单时用到的所有类，要么一个都不用。

解决方案

中介者模式建议你停止组件之间的直接交流并使其相互独立。这些组件必须调用特殊的中介者对象，通过中介者对象重定向调用行为，以间接的方式进行合作。最终，组件仅依赖于一个中介者类，无需与多个其他组件相耦合。

在资料编辑表单的例子中，对话框 （Dialog） 类本身将作为中介者，其很可能已知自己所有的子元素，因此你甚至无需在该类中引入新的依赖关系。

UI 元素必须通过中介者对象进行间接沟通。

绝大部分重要的修改都在实际表单元素中进行。让我们想想提交按钮。之前，当用户点击按钮后，它必须对所有表单元素数值进行校验。而现在它的唯一工作是将点击事件通知给对话框。收到通知后，对话框可以自行校验数值或将任务委派给各元素。这样一来，按钮不再与多个表单元素相关联，而仅依赖于对话框类。

你还可以为所有类型的对话框抽取通用接口，进一步削弱其依赖性。接口中将声明一个所有表单元素都能使用的通知方法，可用于将元素中发生的事件通知给对话框。这样一来，所有实现了该接口的对话框都能使用这个提交按钮了。

采用这种方式，中介者模式让你能在单个中介者对象中封装多个对象间的复杂关系网。类所拥有的依赖关系越少，就越易于修改、 扩展或复用。

中介者模式结构

中介者模式适合应用场景

• 当一些对象和其他对象紧密耦合以致难以对其进行修改时，可使用中介者模式。

  该模式让你将对象间的所有关系抽取成为一个单独的类，以使对于特定组件的修改工作独立于其他组件。

• 当组件因过于依赖其他组件而无法在不同应用中复用时，可使用中介者模式。

  应用中介者模式后，每个组件不再知晓其他组件的情况。尽管这些组件无法直接交流，但它们仍可通过中介者对象进行间接交流。如果你希望在不同应用中复用一个组件，则需要为其提供一个新的中介者类。

• 如果为了能在不同情景下复用一些基本行为，导致你需要被迫创建大量组件子类时，可使用中介者模式。

  由于所有组件间关系都被包含在中介者中，因此你无需修改组件就能方便地新建中介者类以定义新的组件合作方式。

实现方式

1. 找到一组当前紧密耦合，且提供其独立性能带来更大好处的类 （例如更易于维护或更方便复用）。
2. 声明中介者接口并描述中介者和各种组件之间所需的交流接口。在绝大多数情况下，一个接收组件通知的方法就足够了。如果你希望在不同情景下复用组件类，那么该接口将非常重要。只要组件使用通用接口与其中介者合作，你就能将该组件与不同实现中的中介者进行连接。
3. 实现具体中介者类。该类可从自行保存其下所有组件的引用中受益。
4. 你可以更进一步，让中介者负责组件对象的创建和销毁。此后，中介者可能会与工厂或外观类似。
5. 组件必须保存对于中介者对象的引用。该连接通常在组件的构造函数中建立，该函数会将中介者对象作为参数传递。
6. 修改组件代码，使其可调用中介者的通知方法，而非其他组件的方法。然后将调用其他组件的代码抽取到中介者类中，并在中介者接收到该组件通知时执行这些代码。

代码实现

package pattern_dive

import (
	"fmt"
	"testing"
)

// 中介者模式的一个绝佳例子就是火车站交通系统。
// 两列火车互相之间从来不会就站台的空闲状态进行通信。
// station Manager车站经理可充当中介者，让平台仅可由一列入场火车使用，而将其他火车放入队列中等待。
// 离场火车会向车站发送通知，便于队列中的下一列火车进站。
type train interface {
	arrive()
	depart()
	permitArrival()
}

type mediator interface {
	canArrive(train) bool
	notifyAboutDeparture()
}

type stationManager struct {
	isPlatformFree bool
	trainQueue     []train
}
func newStationManger() *stationManager {
	return &stationManager{isPlatformFree: true}
}
func (s *stationManager) canArrive(t train) bool {
	if s.isPlatformFree {
		s.isPlatformFree = false
		return true
	}
	s.trainQueue = append(s.trainQueue, t)
	return false
}
func (s *stationManager) notifyAboutDeparture() {
	if !s.isPlatformFree {
		s.isPlatformFree = true
	}
	if len(s.trainQueue) > 0 {
		firstTrainInQueue := s.trainQueue[0]
		s.trainQueue = s.trainQueue[1:]
		firstTrainInQueue.permitArrival()
	}
}

type passengerTrain struct {
	mediator mediator
}
func (g *passengerTrain) arrive() {
	if !g.mediator.canArrive(g) {
		fmt.Println("PassengerTrain: Arrival blocked, waiting")
		return
	}
	fmt.Println("PassengerTrain: Arrived")
}
func (g *passengerTrain) depart() {
	fmt.Println("PassengerTrain: Leaving")
	g.mediator.notifyAboutDeparture()
}
func (g *passengerTrain) permitArrival() {
	fmt.Println("PassengerTrain: Arrival permitted, arriving")
	g.arrive()
}

type freightTrain struct {
	mediator mediator
}
func (g *freightTrain) arrive() {
	if !g.mediator.canArrive(g) {
		fmt.Println("FreightTrain: Arrival blocked, waiting")
		return
	}
	fmt.Println("FreightTrain: Arrived")
}
func (g *freightTrain) depart() {
	fmt.Println("FreightTrain: Leaving")
	g.mediator.notifyAboutDeparture()
}
func (g *freightTrain) permitArrival() {
	fmt.Println("FreightTrain: Arrival permitted")
	g.arrive()
}

func TestMediator(t *testing.T) {
	stationManager := newStationManger()

	passengerTrain := &passengerTrain{
		mediator: stationManager,
	}
	freightTrain := &freightTrain{
		mediator: stationManager,
	}

	passengerTrain.arrive()
	freightTrain.arrive()
	passengerTrain.depart()
}

中介者模式优缺点

• 单一职责原则。你可以将多个组件间的交流抽取到同一位置，使其更易于理解和维护。
• 开闭原则。你无需修改实际组件就能增加新的中介者。
• 你可以减轻应用中多个组件间的耦合情况。
• 你可以更方便地复用各个组件。

• 一段时间后，中介者可能会演化成为上帝对象。

与其他模式的关系

• 责任链模式、 命令模式、 中介者模式和观察者模式用于处理请求发送者和接收者之间的不同连接方式：

  • 责任链按照顺序将请求动态传递给一系列的潜在接收者，直至其中一名接收者对请求进行处理。
  • 命令在发送者和请求者之间建立单向连接。
  • 中介者清除了发送者和请求者之间的直接连接，强制它们通过一个中介对象进行间接沟通。
  • 观察者允许接收者动态地订阅或取消接收请求。

• 外观模式和中介者的职责类似： 它们都尝试在大量紧密耦合的类中组织起合作。

  • 外观为子系统中的所有对象定义了一个简单接口，但是它不提供任何新功能。子系统本身不会意识到外观的存在。子系统中的对象可以直接进行交流。
  • 中介者将系统中组件的沟通行为中心化。各组件只知道中介者对象，无法直接相互交流。

• 中介者和观察者之间的区别往往很难记住。在大部分情况下，你可以使用其中一种模式，而有时可以同时使用。让我们来看看如何做到这一点。

  中介者的主要目标是消除一系列系统组件之间的相互依赖。这些组件将依赖于同一个中介者对象。观察者的目标是在对象之间建立动态的单向连接，使得部分对象可作为其他对象的附属发挥作用。

  有一种流行的中介者模式实现方式依赖于观察者。中介者对象担当发布者的角色，其他组件则作为订阅者，可以订阅中介者的事件或取消订阅。当中介者以这种方式实现时，它可能看上去与观察者非常相似。

  当你感到疑惑时，记住可以采用其他方式来实现中介者。例如，你可永久性地将所有组件链接到同一个中介者对象。这种实现方式和观察者并不相同，但这仍是一种中介者模式。

  假设有一个程序，其所有的组件都变成了发布者，它们之间可以相互建立动态连接。这样程序中就没有中心化的中介者对象，而只有一些分布式的观察者。

备忘录模式Snapshot(Memento)

备忘录模式是一种行为设计模式，允许在不暴露对象实现细节的情况下保存和恢复对象之前的状态。

为什么使用备忘录模式

假如你正在开发一款文字编辑器应用程序。除了简单的文字编辑功能外，编辑器中还要有设置文本格式和插入内嵌图片等功能。

后来，你决定让用户能撤销施加在文本上的任何操作。这项功能在过去几年里变得十分普遍，因此用户期待任何程序都有这项功能。你选择采用直接的方式来实现该功能： 程序在执行任何操作前会记录所有的对象状态，并将其保存下来。当用户此后需要撤销某个操作时，程序将从历史记录中获取最近的快照，然后使用它来恢复所有对象的状态。

程序在执行操作前保存所有对象的状态快照，稍后可通过快照将对象恢复到之前的状态。

让我们来思考一下这些状态快照。首先，到底该如何生成一个快照呢？ 很可能你会需要遍历对象的所有成员变量并将其数值复制保存。但只有当对象对其内容没有严格访问权限限制的情况下，你才能使用该方式。不过很遗憾，绝大部分对象会使用私有成员变量来存储重要数据，这样别人就无法轻易查看其中的内容。

现在我们暂时忽略这个问题，假设对象都像嬉皮士一样： 喜欢开放式的关系并会公开其所有状态。尽管这种方式能够解决当前问题，让你可随时生成对象的状态快照，但这种方式仍存在一些严重问题。未来你可能会添加或删除一些成员变量。这听上去很简单，但需要对负责复制受影响对象状态的类进行更改。

如何复制对象的私有状态？

还有更多问题。让我们来考虑编辑器（Editor） 状态的实际 “快照”，它需要包含哪些数据？至少必须包含实际的文本、 光标坐标和当前滚动条位置等。你需要收集这些数据并将其放入特定容器中，才能生成快照。

你很可能会将大量的容器对象存储在历史记录列表中。这样一来，容器最终大概率会成为同一个类的对象。这个类中几乎没有任何方法，但有许多与编辑器状态一一对应的成员变量。为了让其他对象能保存或读取快照，你很可能需要将快照的成员变量设为公有。无论这些状态是否私有，其都将暴露一切编辑器状态。其他类会对快照类的每个小改动产生依赖，除非这些改动仅存在于私有成员变量或方法中，而不会影响外部类。

我们似乎走进了一条死胡同： 要么会暴露类的所有内部细节而使其过于脆弱； 要么会限制对其状态的访问权限而无法生成快照。那么，我们还有其他方式来实现 “撤销” 功能吗？

解决方案

我们刚才遇到的所有问题都是封装 “破损” 造成的。一些对象试图超出其职责范围的工作。由于在执行某些行为时需要获取数据，所以它们侵入了其他对象的私有空间，而不是让这些对象来完成实际的工作。

备忘录模式将创建状态快照 （Snapshot） 的工作委派给实际状态的拥有者原发器 （Originator） 对象。这样其他对象就不再需要从 “外部” 复制编辑器状态了，编辑器类拥有其状态的完全访问权，因此可以自行生成快照。

模式建议将对象状态的副本存储在一个名为备忘录 （Memento） 的特殊对象中。除了创建备忘录的对象外，任何对象都不能访问备忘录的内容。其他对象必须使用受限接口与备忘录进行交互，它们可以获取快照的元数据 （创建时间和操作名称等），但不能获取快照中原始对象的状态。

原发器拥有对备忘录的完全访问权限，负责人则只能访问元数据。

这种限制策略允许你将备忘录保存在通常被称为负责人 （Caretakers） 的对象中。由于负责人仅通过受限接口与备忘录互动，故其无法修改存储在备忘录内部的状态。同时，原发器拥有对备忘录所有成员的访问权限，从而能随时恢复其以前的状态。

在文字编辑器的示例中，我们可以创建一个独立的历史 （History） 类作为负责人。编辑器每次执行操作前，存储在负责人中的备忘录栈都会生长。你甚至可以在应用的 UI 中渲染该栈，为用户显示之前的操作历史。

当用户触发撤销操作时，历史类将从栈中取回最近的备忘录，并将其传递给编辑器以请求进行回滚。由于编辑器拥有对备忘录的完全访问权限，因此它可以使用从备忘录中获取的数值来替换自身的状态。

备忘录模式结构

基于嵌套类的实现：

基于中间接口的实现：

另外一种实现方法适用于不支持嵌套类的编程语言 （没错，我说的就是 PHP）。

封装更加严格的实现：

果你不想让其他类有任何机会通过备忘录来访问原发器的状态，那么还有另一种可用的实现方式。

备忘录模式适合应用场景

• 当你需要创建对象状态快照来恢复其之前的状态时，可以使用备忘录模式。

  备忘录模式允许你复制对象中的全部状态 （包括私有成员变量），并将其独立于对象进行保存。尽管大部分人因为 “撤销” 这个用例才记得该模式，但其实它在处理事务 （比如需要在出现错误时回滚一个操作） 的过程中也必不可少。

• 当直接访问对象的成员变量、 获取器或设置器将导致封装被突破时，可以使用该模式。

  备忘录让对象自行负责创建其状态的快照。任何其他对象都不能读取快照，这有效地保障了数据的安全性。

实现方式

1. 确定担任原发器角色的类。重要的是明确程序使用的一个原发器中心对象，还是多个较小的对象。

2. 创建备忘录类。逐一声明对应每个原发器成员变量的备忘录成员变量。

3. 将备忘录类设为不可变。备忘录只能通过构造函数一次性接收数据。该类中不能包含设置器。

4. 如果你所使用的编程语言支持嵌套类，则可将备忘录嵌套在原发器中； 如果不支持，那么你可从备忘录类中抽取一个空接口，然后让其他所有对象通过接口来引用备忘录。你可在该接口中添加一些元数据操作，但不能暴露原发器的状态。

5. 在原发器中添加一个创建备忘录的方法。原发器必须通过备忘录构造函数的一个或多个实际参数来将自身状态传递给备忘录。

   该方法返回结果的类型必须是你在上一步中抽取的接口 （如果你已经抽取了）。实际上，创建备忘录的方法必须直接与备忘录类进行交互。

6. 在原发器类中添加一个用于恢复自身状态的方法。该方法接受备忘录对象作为参数。如果你在之前的步骤中抽取了接口，那么可将接口作为参数的类型。在这种情况下，你需要将输入对象强制转换为备忘录，因为原发器需要拥有对该对象的完全访问权限。

7. 无论负责人是命令对象、 历史记录或其他完全不同的东西，它都必须要知道何时向原发器请求新的备忘录、 如何存储备忘录以及何时使用特定备忘录来对原发器进行恢复。

8. 负责人与原发器之间的连接可以移动到备忘录类中。在本例中，每个备忘录都必须与创建自己的原发器相连接。恢复方法也可以移动到备忘录类中，但只有当备忘录类嵌套在原发器中，或者原发器类提供了足够多的设置器并可对其状态进行重写时，这种方式才能实现。

代码实现

package pattern_dive

import (
	"fmt"
	"testing"
)

// 备忘录
type memento struct {
	state string
}

func (m *memento) getSavedState() string {
	return m.state
}

// 原发器
type originator struct {
	state string
}

func (e *originator) createMemento() *memento {
	return &memento{state: e.state}
}

func (e *originator) restoreMemento(m *memento) {
	e.state = m.getSavedState()
}

func (e *originator) setState(state string) {
	e.state = state
}

func (e *originator) getState() string {
	return e.state
}

// 负责人
type caretaker struct {
	mementoArray []*memento
}

func (c *caretaker) addMemento(m *memento) {
	c.mementoArray = append(c.mementoArray, m)
}

func (c *caretaker) getMemento(index int) *memento {
	return c.mementoArray[index]
}

func TestMemento(t *testing.T) {
	caretaker := &caretaker{
		mementoArray: make([]*memento, 0),
	}

	originator := &originator{
		state: "A",
	}

	fmt.Printf("Originator Current State: %s\n", originator.getState())
	caretaker.addMemento(originator.createMemento())

	originator.setState("B")
	fmt.Printf("Originator Current State: %s\n", originator.getState())
	caretaker.addMemento(originator.createMemento())

	originator.setState("C")
	fmt.Printf("Originator Current State: %s\n", originator.getState())
	caretaker.addMemento(originator.createMemento())

	originator.restoreMemento(caretaker.getMemento(1))
	fmt.Printf("Restored to State: %s\n", originator.getState())

	originator.restoreMemento(caretaker.getMemento(0))
	fmt.Printf("Restored to State: %s\n", originator.getState())
}

备忘录模式优缺点

• 你可以在不破坏对象封装情况的前提下创建对象状态快照。
• 你可以通过让负责人维护原发器状态历史记录来简化原发器代码。

• 如果客户端过于频繁地创建备忘录，程序将消耗大量内存。
• 负责人必须完整跟踪原发器的生命周期，这样才能销毁弃用的备忘录。
• 绝大部分动态编程语言 （例如 PHP、 Python 和 JavaScript） 不能确保备忘录中的状态不被修改。

与其他模式的关系

• 你可以同时使用命令模式和备忘录模式来实现 “撤销”。在这种情况下，命令用于对目标对象执行各种不同的操作，备忘录用来保存一条命令执行前该对象的状态。
• 你可以同时使用备忘录和迭代器模式来获取当前迭代器的状态，并且在需要的时候进行回滚。
• 有时候原型模式可以作为备忘录的一个简化版本，其条件是你需要在历史记录中存储的对象的状态比较简单，不需要链接其他外部资源，或者链接可以方便地重建。

状态模式State

状态模式是一种行为设计模式，让你能在一个对象的内部状态变化时改变其行为，使其看上去就像改变了自身所属的类一样。

为什么使用状态模式

状态模式与有限状态机的概念紧密相关。

其主要思想是程序在任意时刻仅可处于几种有限的状态中。在任何一个特定状态中，程序的行为都不相同，且可瞬间从一个状态切换到另一个状态。不过，根据当前状态，程序可能会切换到另外一种状态，也可能会保持当前状态不变。这些数量有限且预先定义的状态切换规则被称为转移。

你还可将该方法应用在对象上。假如你有一个 文档Document类。文档可能会处于 草稿Draft 、 审阅中Moderation和 已发布Published三种状态中的一种。文档的 publish发布方法在不同状态下的行为略有不同：

• 处于 草稿状态时，它会将文档转移到审阅中状态。
• 处于 审阅中状态时，如果当前用户是管理员，它会公开发布文档。
• 处于 已发布状态时，它不会进行任何操作。

文档对象的全部状态和转移。

状态机通常由众多条件运算符 （ if或 switch ） 实现，可根据对象的当前状态选择相应的行为。 “状态” 通常只是对象中的一组成员变量值。即使你之前从未听说过有限状态机，你也很可能已经实现过状态模式。下面的代码应该能帮助你回忆起来。

class Document is
    field state: string
    // ...
    method publish() is
        switch (state)
            "draft":
                state = "moderation"
                break
            "moderation":
                if (currentUser.role == 'admin')
                    state = "published"
                break
            "published":
                // 什么也不做。
                break
    // ...

当我们逐步在 文档类中添加更多状态和依赖于状态的行为后，基于条件语句的状态机就会暴露其最大的弱点。为了能根据当前状态选择完成相应行为的方法，绝大部分方法中会包含复杂的条件语句。修改其转换逻辑可能会涉及到修改所有方法中的状态条件语句，导致代码的维护工作非常艰难。

这个问题会随着项目进行变得越发严重。我们很难在设计阶段预测到所有可能的状态和转换。随着时间推移，最初仅包含有限条件语句的简洁状态机可能会变成臃肿的一团乱麻。

智能手机的按键和开关会根据设备当前状态完成不同行为：

• 当手机处于解锁状态时，按下按键将执行各种功能。
• 当手机处于锁定状态时，按下任何按键都将解锁屏幕。
• 当手机电量不足时，按下任何按键都将显示充电页面。

解决方案

状态模式建议为对象的所有可能状态新建一个类，然后将所有状态的对应行为抽取到这些类中。

原始对象被称为上下文 （context），它并不会自行实现所有行为，而是会保存一个指向表示当前状态的状态对象的引用，且将所有与状态相关的工作委派给该对象。

文档将工作委派给一个状态对象。

如需将上下文转换为另外一种状态，则需将当前活动的状态对象替换为另外一个代表新状态的对象。采用这种方式是有前提的： 所有状态类都必须遵循同样的接口，而且上下文必须仅通过接口与这些对象进行交互。

这个结构可能看上去与策略模式相似，但有一个关键性的不同——在状态模式中，特定状态知道其他所有状态的存在，且能触发从一个状态到另一个状态的转换； 策略则几乎完全不知道其他策略的存在。

状态模式结构

状态模式适合应用场景

• 如果对象需要根据自身当前状态进行不同行为，同时状态的数量非常多且与状态相关的代码会频繁变更的话，可使用状态模式。

  模式建议你将所有特定于状态的代码抽取到一组独立的类中。这样一来，你可以在独立于其他状态的情况下添加新状态或修改已有状态，从而减少维护成本。

• 如果某个类需要根据成员变量的当前值改变自身行为，从而需要使用大量的条件语句时，可使用该模式。

  状态模式会将这些条件语句的分支抽取到相应状态类的方法中。同时，你还可以清除主要类中与特定状态相关的临时成员变量和帮手方法代码。

• 当相似状态和基于条件的状态机转换中存在许多重复代码时，可使用状态模式。

  状态模式让你能够生成状态类层次结构，通过将公用代码抽取到抽象基类中来减少重复。

实现方式

1. 确定哪些类是上下文。它可能是包含依赖于状态的代码的已有类； 如果特定于状态的代码分散在多个类中，那么它可能是一个新的类。

2. 声明状态接口。虽然你可能会需要完全复制上下文中声明的所有方法，但最好是仅把关注点放在那些可能包含特定于状态的行为的方法上。

3. 为每个实际状态创建一个继承于状态接口的类。然后检查上下文中的方法并将与特定状态相关的所有代码抽取到新建的类中。

   在将代码移动到状态类的过程中，你可能会发现它依赖于上下文中的一些私有成员。你可以采用以下几种变通方式：

   • 将这些成员变量或方法设为公有。
   • 将需要抽取的上下文行为更改为上下文中的公有方法，然后在状态类中调用。这种方式简陋却便捷，你可以稍后再对其进行修补。
   • 将状态类嵌套在上下文类中。这种方式需要你所使用的编程语言支持嵌套类。

4. 在上下文类中添加一个状态接口类型的引用成员变量，以及一个用于修改该成员变量值的公有设置器。

5. 再次检查上下文中的方法，将空的条件语句替换为相应的状态对象方法。

6. 为切换上下文状态，你需要创建某个状态类实例并将其传递给上下文。你可以在上下文、 各种状态或客户端中完成这项工作。无论在何处完成这项工作，该类都将依赖于其所实例化的具体类。

代码实现

package pattern_dive

import (
	"fmt"
	"log"
	"testing"
)

// 为简单起见，让我们假设自动售货机仅会销售一种类型的商品。假设自动售货机可处于 4 种不同的状态中：
// 有商品（has Item）, 无商品（no Item）, 商品已请求（item Requested）, 收到纸币（has Money）

// 同时，自动售货机也会有不同的操作。假设其只会执行 4 种操作：
// 选择商品, 添加商品, 插入纸币, 提供商品

// 当对象可以处于许多不同的状态中时应使用状态设计模式，同时根据传入请求的不同，对象需要变更其当前状态。
// 在我们的例子中，自动售货机可以有多种不同的状态，同时会在这些状态之间持续不断地互相转换。

// 我们假设自动售货机处于 商品已请求状态中。在 “插入纸币” 的操作发生后，机器将自动转换至 收到纸币状态。
// 根据其当前状态，机器可就相同请求采取不同的行为。例如，如果用户想要购买一件商品，机器将在 有商品状态时继续操作，而在 无商品状态时拒绝操作。
// 自动售货机的代码不会被这一逻辑污染； 所有依赖于状态的代码都存在于各自的状态实现中。

type state interface {
	addItem(int) error
	requestItem() error
	insertMoney(money int) error
	dispenseItem() error
}

// 自动贩卖机
type vendingMachine struct {
	hasItem       state
	itemRequested state
	hasMoney      state
	noItem        state

	currentState state

	itemCount int
	itemPrice int
}

func newVendingMachine(itemCount, itemPrice int) *vendingMachine {
	v := &vendingMachine{
		itemCount: itemCount,
		itemPrice: itemPrice,
	}
	hasItemState := &hasItemState{vendingMachine: v}
	itemRequestedState := &itemRequestedState{vendingMachine: v}
	hasMoneyState := &hasMoneyState{vendingMachine: v}
	noItemState := &noItemState{vendingMachine: v}

	v.setState(hasItemState)
	v.hasItem = hasItemState
	v.itemRequested = itemRequestedState
	v.hasMoney = hasMoneyState
	v.noItem = noItemState
	return v
}

func (v *vendingMachine) requestItem() error {
	return v.currentState.requestItem()
}

func (v *vendingMachine) addItem(count int) error {
	return v.currentState.addItem(count)
}

func (v *vendingMachine) insertMoney(money int) error {
	return v.currentState.insertMoney(money)
}

func (v *vendingMachine) dispenseItem() error {
	return v.currentState.dispenseItem()
}

func (v *vendingMachine) setState(s state) {
	v.currentState = s
}

func (v *vendingMachine) incrementItemCount(count int) {
	fmt.Printf("Adding %d items\n", count)
	v.itemCount = v.itemCount + count
}

type noItemState struct {
	vendingMachine *vendingMachine
}

func (i *noItemState) addItem(count int) error {
	i.vendingMachine.incrementItemCount(count)
	i.vendingMachine.setState(i.vendingMachine.hasItem)
	return nil
}

func (i *noItemState) requestItem() error {
	return fmt.Errorf("item out of stock")
}

func (i *noItemState) insertMoney(money int) error {
	return fmt.Errorf("item out of stock")
}
func (i *noItemState) dispenseItem() error {
	return fmt.Errorf("item out of stock")
}

type hasItemState struct {
	vendingMachine *vendingMachine
}

func (i *hasItemState) requestItem() error {
	if i.vendingMachine.itemCount == 0 {
		i.vendingMachine.setState(i.vendingMachine.noItem)
		return fmt.Errorf("no item present")
	}
	fmt.Printf("Item requestd\n")
	i.vendingMachine.setState(i.vendingMachine.itemRequested)
	return nil
}

func (i *hasItemState) addItem(count int) error {
	fmt.Printf("%d items added\n", count)
	i.vendingMachine.incrementItemCount(count)
	return nil
}

func (i *hasItemState) insertMoney(money int) error {
	return fmt.Errorf("please select item first")
}
func (i *hasItemState) dispenseItem() error {
	return fmt.Errorf("please select item first")
}

type itemRequestedState struct {
	vendingMachine *vendingMachine
}

func (i *itemRequestedState) requestItem() error {
	return fmt.Errorf("item already requested")
}

func (i *itemRequestedState) addItem(count int) error {
	return fmt.Errorf("item Dispense in progress")
}

func (i *itemRequestedState) insertMoney(money int) error {
	if money < i.vendingMachine.itemPrice {
		fmt.Errorf("inserted money is less. Please insert %d", i.vendingMachine.itemPrice)
	}
	fmt.Println("Money entered is ok")
	i.vendingMachine.setState(i.vendingMachine.hasMoney)
	return nil
}
func (i *itemRequestedState) dispenseItem() error {
	return fmt.Errorf("please insert money first")
}

type hasMoneyState struct {
	vendingMachine *vendingMachine
}

func (i *hasMoneyState) requestItem() error {
	return fmt.Errorf("item dispense in progress")
}

func (i *hasMoneyState) addItem(count int) error {
	return fmt.Errorf("item dispense in progress")
}

func (i *hasMoneyState) insertMoney(money int) error {
	return fmt.Errorf("item out of stock")
}
func (i *hasMoneyState) dispenseItem() error {
	fmt.Println("Dispensing Item")
	i.vendingMachine.itemCount = i.vendingMachine.itemCount - 1
	if i.vendingMachine.itemCount == 0 {
		i.vendingMachine.setState(i.vendingMachine.noItem)
	} else {
		i.vendingMachine.setState(i.vendingMachine.hasItem)
	}
	return nil
}

func TestState(t *testing.T) {
	vendingMachine := newVendingMachine(1, 10)
	if err := vendingMachine.requestItem(); err != nil {
		log.Fatalf(err.Error())
	}

	if err := vendingMachine.insertMoney(10); err != nil {
		log.Fatalf(err.Error())
	}

	if err := vendingMachine.dispenseItem(); err != nil {
		log.Fatalf(err.Error())
	}

	if err := vendingMachine.addItem(2); err != nil {
		log.Fatalf(err.Error())
	}

	if err := vendingMachine.requestItem(); err != nil {
		log.Fatalf(err.Error())
	}

	if err := vendingMachine.insertMoney(10); err != nil {
		log.Fatalf(err.Error())
	}

	if err := vendingMachine.dispenseItem(); err != nil {
		log.Fatalf(err.Error())
	}
}

状态模式优缺点

• 单一职责原则。将与特定状态相关的代码放在单独的类中。
• 开闭原则。无需修改已有状态类和上下文就能引入新状态。
• 通过消除臃肿的状态机条件语句简化上下文代码。

• 如果状态机只有很少的几个状态，或者很少发生改变，那么应用该模式可能会显得小题大作。

与其他模式的关系

• 桥接模式、 状态模式和策略模式 （在某种程度上包括适配器模式） 模式的接口非常相似。实际上，它们都基于组合模式——即将工作委派给其他对象，不过也各自解决了不同的问题。模式并不只是以特定方式组织代码的配方，你还可以使用它们来和其他开发者讨论模式所解决的问题。
• 状态可被视为策略的扩展。两者都基于组合机制： 它们都通过将部分工作委派给 “帮手” 对象来改变其在不同情景下的行为。策略使得这些对象相互之间完全独立，它们不知道其他对象的存在。但状态模式没有限制具体状态之间的依赖，且允许它们自行改变在不同情景下的状态。

模板方法模式Template Method

模板方法模式是一种行为设计模式，它在超类中定义了一个算法的框架，允许子类在不修改结构的情况下重写算法的特定步骤。

为什么使用模版方法模式

假如你正在开发一款分析公司文档的数据挖掘程序。用户需要向程序输入各种格式 （PDF、 DOC 或 CSV） 的文档，程序则会试图从这些文件中抽取有意义的数据，并以统一的格式将其返回给用户。

该程序的首个版本仅支持 DOC 文件。在接下来的一个版本中，程序能够支持 CSV 文件。一个月后，你 “教会” 了程序从 PDF 文件中抽取数据。

数据挖掘类中包含许多重复代码。

一段时间后，你发现这三个类中包含许多相似代码。尽管这些类处理不同数据格式的代码完全不同，但数据处理和分析的代码却几乎完全一样。如果能在保持算法结构完整的情况下去除重复代码，这难道不是一件很棒的事情吗？

还有另一个与使用这些类的客户端代码相关的问题： 客户端代码中包含许多条件语句，以根据不同的处理对象类型选择合适的处理过程。如果所有处理数据的类都拥有相同的接口或基类，那么你就可以去除客户端代码中的条件语句，转而使用多态机制来在处理对象上调用函数。

解决方案

模板方法模式建议将算法分解为一系列步骤，然后将这些步骤改写为方法，最后在 “模板方法” 中依次调用这些方法。步骤可以是 抽象的，也可以有一些默认的实现。为了能够使用算法，客户端需要自行提供子类并实现所有的抽象步骤。如有必要还需重写一些步骤 （但这一步中不包括模板方法自身）。

让我们考虑如何在数据挖掘应用中实现上述方案。我们可为图中的三个解析算法创建一个基类，该类将定义调用了一系列不同文档处理步骤的模板方法。

模板方法将算法分解为步骤，并允许子类重写这些步骤，而非重写实际的模板方法。

首先，我们将所有步骤声明为 抽象类型，强制要求子类自行实现这些方法。在我们的例子中，子类中已有所有必要的实现，因此我们只需调整这些方法的签名，使之与超类的方法匹配即可。

现在，让我们看看如何去除重复代码。对于不同的数据格式，打开和关闭文件以及抽取和解析数据的代码都不同，因此无需修改这些方法。但分析原始数据和生成报告等其他步骤的实现方式非常相似，因此可将其提取到基类中，以让子类共享这些代码。

正如你所看到的那样，我们有两种类型的步骤：

• 抽象步骤必须由各个子类来实现
• 可选步骤已有一些默认实现，但仍可在需要时进行重写

还有另一种名为钩子的步骤。钩子是内容为空的可选步骤。即使不重写钩子，模板方法也能工作。钩子通常放置在算法重要步骤的前后，为子类提供额外的算法扩展点。

模板方法模式结构

模板方法模式适合应用场景

• 当你只希望客户端扩展某个特定算法步骤，而不是整个算法或其结构时，可使用模板方法模式。

  模板方法将整个算法转换为一系列独立的步骤，以便子类能对其进行扩展，同时还可让超类中所定义的结构保持完整。

• 当多个类的算法除一些细微不同之外几乎完全一样时，你可使用该模式。但其后果就是，只要算法发生变化，你就可能需要修改所有的类。

  在将算法转换为模板方法时，你可将相似的实现步骤提取到超类中以去除重复代码。子类间各不同的代码可继续保留在子类中。

实现方式

1. 分析目标算法，确定能否将其分解为多个步骤。从所有子类的角度出发，考虑哪些步骤能够通用，哪些步骤各不相同。
2. 创建抽象基类并声明一个模板方法和代表算法步骤的一系列抽象方法。在模板方法中根据算法结构依次调用相应步骤。可用 final最终修饰模板方法以防止子类对其进行重写。
3. 虽然可将所有步骤全都设为抽象类型，但默认实现可能会给部分步骤带来好处，因为子类无需实现那些方法。
4. 可考虑在算法的关键步骤之间添加钩子。
5. 为每个算法变体新建一个具体子类，它必须实现所有的抽象步骤，也可以重写部分可选步骤。

代码实现

package pattern_dive

// 一次性密码功能(OTP)
// 将 OTP 传递给用户的方式多种多样 （短信、 邮件等）。但无论是短信还是邮件，整个 OTP 流程都是相同的：
// 1.生成随机的 n 位数字。
// 2.在缓存中保存这组数字以便进行后续验证。
// 3.准备内容。
// 4.发送通知。
// 5.发布。

// 后续引入的任何新 OTP 类型都很有可能需要进行相同的上述步骤。
// 因此，我们会有这样的一个场景，其中某个特定操作的步骤是相同的，但实现方式却可能有所不同。这正是适合考虑使用模板方法模式的情况。
// 首先，我们定义一个由固定数量的方法组成的基础模板算法。这就是我们的模板方法。然后我们将实现每一个步骤方法，但不会改变模板方法。
import (
	"fmt"
	"testing"
)

type iOtp interface {
	genRandomOTP(int) string
	saveOTPCache(string)
	getMessage(string) string
	sendNotification(string) error
	publishMetric()
}

type otp struct {
	iOtp iOtp
}

func (o *otp) genAndSendOTP(otpLength int) error {
	otp := o.iOtp.genRandomOTP(otpLength)
	o.iOtp.saveOTPCache(otp)
	message := o.iOtp.getMessage(otp)
	err := o.iOtp.sendNotification(message)
	if err != nil {
		return err
	}
	o.iOtp.publishMetric()
	return nil
}

type sms struct {
	otp
}
func (s *sms) genRandomOTP(len int) string {
	randomOTP := "1234"
	fmt.Printf("SMS: generating random otp %s\n", randomOTP)
	return randomOTP
}
func (s *sms) saveOTPCache(otp string) {
	fmt.Printf("SMS: saving otp: %s to cache\n", otp)
}
func (s *sms) getMessage(otp string) string {
	return "SMS OTP for login is " + otp
}
func (s *sms) sendNotification(message string) error {
	fmt.Printf("SMS: sending sms: %s\n", message)
	return nil
}
func (s *sms) publishMetric() {
	fmt.Printf("SMS: publishing metrics\n")
}

type email struct {
	otp
}
func (s *email) genRandomOTP(len int) string {
	randomOTP := "1234"
	fmt.Printf("EMAIL: generating random otp %s\n", randomOTP)
	return randomOTP
}
func (s *email) saveOTPCache(otp string) {
	fmt.Printf("EMAIL: saving otp: %s to cache\n", otp)
}
func (s *email) getMessage(otp string) string {
	return "EMAIL OTP for login is " + otp
}
func (s *email) sendNotification(message string) error {
	fmt.Printf("EMAIL: sending email: %s\n", message)
	return nil
}
func (s *email) publishMetric() {
	fmt.Printf("EMAIL: publishing metrics\n")
}

func TestTemplateMethod(t *testing.T) {
	smsOTP := &sms{}
	o := otp{
		iOtp: smsOTP,
	}
	o.genAndSendOTP(4)
	
	emailOTP := &email{}
	o = otp{
		iOtp: emailOTP,
	}
	o.genAndSendOTP(4)

}

模板方法模式优缺点

• 你可仅允许客户端重写一个大型算法中的特定部分，使得算法其他部分修改对其所造成的影响减小。

• 你可将重复代码提取到一个超类中。

• 部分客户端可能会受到算法框架的限制。

• 通过子类抑制默认步骤实现可能会导致违反_里氏替换原则_。
• 模板方法中的步骤越多，其维护工作就可能会越困难。

与其他模式的关系

• 工厂方法模式是模板方法模式的一种特殊形式。同时，工厂方法可以作为一个大型模板方法中的一个步骤。
• 模板方法基于继承机制： 它允许你通过扩展子类中的部分内容来改变部分算法。策略模式基于组合机制： 你可以通过对相应行为提供不同的策略来改变对象的部分行为。模板方法在类层次上运作，因此它是静态的。策略在对象层次上运作，因此允许在运行时切换行为。

访问者模式Visitor

访问者模式是一种行为设计模式，它能将算法与其所作用的对象隔离开来。

为什么使用访问者模式

假如你的团队开发了一款能够使用巨型图像中地理信息的应用程序。图像中的每个节点既能代表复杂实体 （例如一座城市），也能代表更精细的对象 （例如工业区和旅游景点等）。如果节点代表的真实对象之间存在公路，那么这些节点就会相互连接。在程序内部，每个节点的类型都由其所属的类来表示，每个特定的节点则是一个对象。

一段时间后，你接到了实现将图像导出到 XML 文件中的任务。这些工作最初看上去非常简单。你计划为每个节点类添加导出函数，然后递归执行图像中每个节点的导出函数。解决方案简单且优雅： 使用多态机制可以让导出方法的调用代码不会和具体的节点类相耦合。

但你不太走运，系统架构师拒绝批准对已有节点类进行修改。他认为这些代码已经是产品了，不想冒险对其进行修改，因为修改可能会引入潜在的缺陷。

所有节点的类中都必须添加导出至 XML 文件的方法，但如果在修改代码的过程中引入了任何缺陷，那么整个程序都会面临风险。

此外，他还质疑在节点类中包含导出 XML 文件的代码是否有意义。这些类的主要工作是处理地理数据。导出 XML 文件的代码放在这里并不合适。

还有另一个原因，那就是在此项任务完成后，营销部门很有可能会要求程序提供导出其他类型文件的功能，或者提出其他奇怪的要求。这样你很可能会被迫再次修改这些重要但脆弱的类。

解决方案

访问者模式建议将新行为放入一个名为访问者的独立类中，而不是试图将其整合到已有类中。现在，需要执行操作的原始对象将作为参数被传递给访问者中的方法，让方法能访问对象所包含的一切必要数据。

如果现在该操作能在不同类的对象上执行会怎么样呢？ 比如在我们的示例中，各节点类导出 XML 文件的实际实现很可能会稍有不同。因此，访问者类可以定义一组 （而不是一个） 方法，且每个方法可接收不同类型的参数，如下所示：

class ExportVisitor implements Visitor is
    method doForCity(City c) { ... }
    method doForIndustry(Industry f) { ... }
    method doForSightSeeing(SightSeeing ss) { ... }
    // ...

但我们究竟应该如何调用这些方法 （尤其是在处理整个图像方面） 呢？ 这些方法的签名各不相同，因此我们不能使用多态机制。为了可以挑选出能够处理特定对象的访问者方法，我们需要对它的类进行检查。这是不是听上去像个噩梦呢？

foreach (Node node in graph)
    if (node instanceof City)
        exportVisitor.doForCity((City) node)
    if (node instanceof Industry)
        exportVisitor.doForIndustry((Industry) node)
    // ...
}

你可能会问，我们为什么不使用方法重载呢？ 就是使用相同的方法名称，但它们的参数不同。不幸的是，即使我们的编程语言 （例如 Java 和 C#） 支持重载也不行。由于我们无法提前知晓节点对象所属的类，所以重载机制无法执行正确的方法。方法会将 节点基类作为输入参数的默认类型。

但是，访问者模式可以解决这个问题。它使用了一种名为双分派的技巧，不使用累赘的条件语句也可下执行正确的方法。与其让客户端来选择调用正确版本的方法，不如将选择权委派给作为参数传递给访问者的对象。由于该对象知晓其自身的类，因此能更自然地在访问者中选出正确的方法。它们会 “接收” 一个访问者并告诉其应执行的访问者方法。

// 客户端代码
foreach (Node node in graph)
    node.accept(exportVisitor)

// 城市
class City is
    method accept(Visitor v) is
        v.doForCity(this)
    // ...

// 工业区
class Industry is
    method accept(Visitor v) is
        v.doForIndustry(this)
    // ...

我承认最终还是修改了节点类，但毕竟改动很小，且使得我们能够在后续进一步添加行为时无需再次修改代码。

现在，如果我们抽取出所有访问者的通用接口，所有已有的节点都能与我们在程序中引入的任何访问者交互。如果需要引入与节点相关的某个行为，你只需要实现一个新的访问者类即可。

访问者模式结构

访问者模式适合应用场景

• 如果你需要对一个复杂对象结构 （例如对象树） 中的所有元素执行某些操作，可使用访问者模式。

  访问者模式通过在访问者对象中为多个目标类提供相同操作的变体，让你能在属于不同类的一组对象上执行同一操作。

• 可使用访问者模式来清理辅助行为的业务逻辑。

  该模式会将所有非主要的行为抽取到一组访问者类中，使得程序的主要类能更专注于主要的工作。

• 当某个行为仅在类层次结构中的一些类中有意义，而在其他类中没有意义时，可使用该模式。

  你可将该行为抽取到单独的访问者类中，只需实现接收相关类的对象作为参数的访问者方法并将其他方法留空即可。

实现方式

1. 在访问者接口中声明一组 “访问” 方法，分别对应程序中的每个具体元素类。

2. 声明元素接口。如果程序中已有元素类层次接口，可在层次结构基类中添加抽象的 “接收” 方法。该方法必须接受访问者对象作为参数。

3. 在所有具体元素类中实现接收方法。这些方法必须将调用重定向到当前元素对应的访问者对象中的访问者方法上。

4. 元素类只能通过访问者接口与访问者进行交互。不过访问者必须知晓所有的具体元素类，因为这些类在访问者方法中都被作为参数类型引用。

5. 为每个无法在元素层次结构中实现的行为创建一个具体访问者类并实现所有的访问者方法。

   你可能会遇到访问者需要访问元素类的部分私有成员变量的情况。在这种情况下，你要么将这些变量或方法设为公有，这将破坏元素的封装； 要么将访问者类嵌入到元素类中。后一种方式只有在支持嵌套类的编程语言中才可能实现。

6. 客户端必须创建访问者对象并通过 “接收” 方法将其传递给元素。

代码实现

package pattern_dive

// 访问者模式允许你在结构体中添加行为，而又不会对结构体造成实际变更。
// 假设你是一个代码库的维护者，代码库中包含不同的形状结构体，如：
// - 方形
// - 圆形
// - 三角形

// 上述每个形状结构体都实现了通用形状接口。
// 有个团队请求你在形状结构体中添加getArea获取面积行为。

// 解决这一问题的办法有很多。
// - 第一个选项便是将getArea方法直接添加至形状接口，然后在各个形状结构体中进行实现。这似乎是比较好的解决方案，但其代价也比较高。
// - 第二个选项是请求功能的团队自行实现行为。然而这并不总是可行，因为行为可能会依赖于私有代码。
// - 第三个方法就是使用访问者模式来解决上述问题。

// 首先定义一个如下访问者接口：
//type visitor interface {
//    visitForSquare(square)
//    visitForCircle(circle)
//    visitForTriangle(triangle)
//}
// 我们可以使用visitForSquare(square) 、visitForCircle(circle)以及visitForTriangle(triangle)函数来为方形、 圆形以及三角形添加相应的功能。
// 你可能在想，为什么我们不再访问者接口里面使用单一的 visit(shape)方法呢？ 这是因为 Go 语言不支持方法重载，所以你无法以相同名称、 不同参数的方式来使用方法。

// 第二项重要的工作是将 accept 接受方法添加至形状接口中。
// func accept(v visitor)，所有形状结构体都需要定义此方法
// 等等，我刚才是不是提到过，我们并不想修改现有的形状结构体？ 很不幸，在使用访问者模式时，我们必须要修改形状结构体。但这样的修改只需要进行一次。
// 如果添加任何其他行为，比如getNumSides获取边数和getMiddleCoordinates获取中点坐标，我们将使用相同的 accept(v visitor)函数，而无需对形状结构体进行进一步的修改。
//最后，形状结构体只需要修改一次，并且所有未来针对不同行为的请求都可以使用相同的 accept 函数来进行处理。如果团队成员请求getArea行为，我们只需简单地定义访问者接口的具体实现，并在其中编写面积的计算逻辑即可。
import (
	"fmt"
	"testing"
)

type shape interface {
	getType() string
	accept(visitor)
}

type square struct {
	side int
}
func (s *square) getType() string  { return "Square" }
func (s *square) accept(v visitor) { v.visitForSquare(s) }

type circle struct {
	radius int
}
func (c *circle) getType() string  { return "Circle" }
func (c *circle) accept(v visitor) { v.visitForCircle(c) }

type rectangle struct {
	l int
	b int
}
func (t *rectangle) getType() string  { return "rectangle" }
func (t *rectangle) accept(v visitor) { v.visitForRectangle(t) }


type visitor interface {
	visitForSquare(*square)
	visitForCircle(*circle)
	visitForRectangle(*rectangle)
}

// 计算面积
type areaCalculator struct {
	area int
}
// 计算面积,然后将结果赋给area变量
func (a *areaCalculator) visitForSquare(s *square) { fmt.Println("Calculating area for square") }
func (a *areaCalculator) visitForCircle(s *circle) { fmt.Println("Calculating area for circle") }
func (a *areaCalculator) visitForRectangle(s *rectangle) { fmt.Println("Calculating area for rectangle") }

// 中间坐标
type middleCoordinates struct {
	x int
	y int
}
// 计算中点坐标,然后将结果赋给x,y变量
func (a *middleCoordinates) visitForSquare(s *square) { fmt.Println("Calculating middle point coordinates for square") }
func (a *middleCoordinates) visitForCircle(c *circle) { fmt.Println("Calculating middle point coordinates for circle") }
func (a *middleCoordinates) visitForRectangle(t *rectangle) { fmt.Println("Calculating middle point coordinates for rectangle") }

func TestVisitor(t *testing.T) {
	square := &square{side: 2}
	circle := &circle{radius: 3}
	rectangle := &rectangle{l: 2, b: 3}

	areaCalculator := &areaCalculator{}
	middleCoordinates := &middleCoordinates{}

	square.accept(areaCalculator)
	circle.accept(areaCalculator)
	rectangle.accept(areaCalculator)

	square.accept(middleCoordinates)
	circle.accept(middleCoordinates)
	rectangle.accept(middleCoordinates)
}

• 每一种visitor就是一种行为
• 每一种visitor的方法按照context类进行分类

访问者模式优缺点

• 开闭原则。你可以引入在不同类对象上执行的新行为，且无需对这些类做出修改。
• 单一职责原则。可将同一行为的不同版本移到同一个类中。
• 访问者对象可以在与各种对象交互时收集一些有用的信息。当你想要遍历一些复杂的对象结构 （例如对象树），并在结构中的每个对象上应用访问者时，这些信息可能会有所帮助。

• 每次在元素层次结构中添加或移除一个类时，你都要更新所有的访问者。
• 在访问者同某个元素进行交互时，它们可能没有访问元素私有成员变量和方法的必要权限。

与其他模式的关系

• 你可以将访问者模式视为命令模式的加强版本，其对象可对不同类的多种对象执行操作。
• 你可以使用访问者对整个组合模式树执行操作。
• 可以同时使用访问者和迭代器模式来遍历复杂数据结构，并对其中的元素执行所需操作，即使这些元素所属的类完全不同。