行为型模式 #
1.模版方法模式 #
在模板模式（Template Pattern）中，一个抽象类公开定义了执行它的方法的方式/模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行。模版方法模式中的角色与职责如下：
- AbstractClass（抽象类）：在抽象类中定义了一系列基本操作(PrimitiveOperations)，这些基本操作可以是具体的，也可以是抽象的，每一个基本操作对应算法的一个步骤，在其子类中可以重定义或实现这些步骤。同时，在抽象类中实现了一个模板方法(Template Method)，用于定义一个算法的框架，模板方法不仅可以调用在抽象类中实现的基本方法，也可以调用在抽象类的子类中实现的基本方法，还可以调用其他对象中的方法。
- ConcreteClass（具体子类）：它是抽象类的子类，用于实现在父类中声明的抽象基本操作以完成子类特定算法的步骤，也可以覆盖在父类中已经实现的具体基本操作。
package main
import "fmt"
type WorkInterface interface {
GetUp()
Work()
Sleep()
}
type worker struct {
WorkInterface
}
func NewWorker(w WorkInterface) worker {
return worker{WorkInterface: w}
}
func (w worker) Daily() {
w.GetUp()
w.Work()
w.Sleep()
}
//具体子类
type Coder struct {}
func (Coder) GetUp() {
fmt.Println("coder get up")
}
func (Coder) Work() {
fmt.Println("coder work")
}
func (Coder) Sleep() {
fmt.Println("coder sleep")
}
type Farmer struct {}
func (Farmer) GetUp() {
fmt.Println("farmer get up")
}
func (Farmer) Work() {
fmt.Println("farmer work")
}
func (Farmer) Sleep() {
fmt.Println("farmer sleep")
}
func main() {
worker1 := NewWorker(Coder{})
worker1.Daily()
fmt.Println("---------------")
worker2 := NewWorker(Farmer{})
worker2.Daily()
}优点：
- 在父类中形式化地定义一个算法，而由它的子类来实现细节的处理，在子类实现详细的处理算法时并不会改变算法中步骤的执行次序。
- 模板方法模式是一种代码复用技术，它在类库设计中尤为重要，它提取了类库中的公共行为，将公共行为放在父类中，而通过其子类来实现不同的行为，它鼓励我们恰当使用继承来实现代码复用。
- 可实现一种反向控制结构，通过子类覆盖父类的钩子方法来决定某一特定步骤是否需要执行。
- 在模板方法模式中可以通过子类来覆盖父类的基本方法，不同的子类可以提供基本方法的不同实现，更换和增加新的子类很方便，符合单一职责原则和开闭原则。
缺点：
- 需要为每一个基本方法的不同实现提供一个子类，如果父类中可变的基本方法太多，将会导致类的个数增加，系统更加庞大，设计也更加抽象。
适用场景：
- 具有统一的操作步骤或操作过程。
- 具有不同的操作细节。
2.命令模式 #
命令模式将一个请求封装为一个对象，从而让我们可以用不同的请求对客户进行参数化。命令模式可以将请求发送者和接收者完全解耦，发送者与接收者之间没有直接引用关系，发送请求的对象只需要知道如何发送请求，而不必知道如何完成请求。命令模式中的角色与职责如下：
- Command（抽象命令类）：抽象命令类一般是一个抽象类或接口，在其中声明了用于执行请求的execute()等方法，通过这些方法可以调用请求接收者的相关操作。
- ConcreteCommand（具体命令类）：具体命令类是抽象命令类的子类，实现了在抽象命令类中声明的方法，它对应具体的接收者对象，将接收者对象的动作绑定其中。在实现execute()方法时，将调用接收者对象的相关操作(Action)。
- Invoker（调用者）：调用者即请求发送者，它通过命令对象来执行请求。一个调用者并不需要在设计时确定其接收者，因此它只与抽象命令类之间存在关联关系。在程序运行时可以将一个具体命令对象注入其中，再调用具体命令对象的execute()方法，从而实现间接调用请求接收者的相关操作。
- Receiver（接收者）：接收者执行与请求相关的操作，它具体实现对请求的业务处理。
package main
import "fmt"
//doctor 命令接收者
type Doctor struct {}
func (d *Doctor) treatEye() {
fmt.Println("医生治疗眼睛")
}
func (d *Doctor) treatNose() {
fmt.Println("医生治疗鼻子")
}
//抽象命令
type Command interface {
Treat()
}
//具体命令
type CommandTreatEye struct {
doctor *Doctor
}
func (cmd *CommandTreatEye) Treat() {
cmd.doctor.treatEye()
}
type CommandTreatNose struct {
doctor *Doctor
}
func (cmd *CommandTreatNose) Treat() {
cmd.doctor.treatNose()
}
//命令调用者 护士
type Nurse struct {
CmdList []Command
}
func (n *Nurse) Notify() {
for _, cmd := range n.CmdList {
cmd.Treat()
}
}
func main() {
//接收者 医生
doctor := new(Doctor)
//治疗眼睛的病单
cmdEye := &CommandTreatEye{doctor: doctor}
//治疗鼻子的病单
cmdNose := &CommandTreatNose{doctor: doctor}
//护士
nurse := new(Nurse)
nurse.CmdList = append(nurse.CmdList, cmdEye)
nurse.CmdList = append(nurse.CmdList, cmdNose)
//执行病单命令
nurse.Notify()
}优点：
- 降低系统的耦合度。由于请求者与接收者之间不存在直接引用，因此请求者与接收者之间实现完全解耦，相同的请求者可以对应不同的接收者，同样，相同的接收者也可以供不同的请求者使用，两者之间具有良好的独立性。
- 新的命令可以很容易地加入到系统中。由于增加新的具体命令类不会影响到其他类，因此增加新的具体命令类很容易，无须修改原有系统源代码，甚至客户类代码，满足“开闭原则”的要求。
- 可以比较容易地设计一个命令队列或宏命令（组合命令）。
缺点：
- 使用命令模式可能会导致某些系统有过多的具体命令类。因为针对每一个对请求接收者的调用操作都需要设计一个具体命令类，因此在某些系统中可能需要提供大量的具体命令类，这将影响命令模式的使用。
适用场景：
- 系统需要将请求调用者和请求接收者解耦，使得调用者和接收者不直接交互。请求调用者无须知道接收者的存在，也无须知道接收者是谁，接收者也无须关心何时被调用。
- 系统需要在不同的时间指定请求、将请求排队和执行请求。一个命令对象和请求的初始调用者可以有不同的生命期，换言之，最初的请求发出者可能已经不在了，而命令对象本身仍然是活动的，可以通过该命令对象去调用请求接收者，而无须关心请求调用者的存在性，可以通过请求日志文件等机制来具体实现。
- 系统需要将一组操作组合在一起形成宏命令。
3.策略模式 #
在策略模式中，一个类的行为或者算法可以在运行时更改。在策略模式中，我们创建表示各种策略的对象和一个行为随着策略对象改变而改变的 context 对象。策略对象改变 context 对象的执行算法。策略模式中的角色与职责如下：
- Context（环境类）：环境类是使用算法的角色，它在解决某个问题（即实现某个方法）时可以采用多种策略。在环境类中维持一个对抽象策略类的引用实例，用于定义所采用的策略。
- Strategy（抽象策略类）：它为所支持的算法声明了抽象方法，是所有策略类的父类，它可以是抽象类或具体类，也可以是接口。环境类通过抽象策略类中声明的方法在运行时调用具体策略类中实现的算法。
- ConcreteStrategy（具体策略类）：它实现了在抽象策略类中声明的算法，在运行时，具体策略类将覆盖在环境类中定义的抽象策略类对象，使用一种具体的算法实现某个业务处理。
package main
import "fmt"
//抽象策略类
type WeaponStrategy interface {
UseWeapon() //使用武器
}
//具体的策略
type Ak47 struct {}
func (*Ak47) UseWeapon() {
fmt.Println("使用ak47 去战斗")
}
type Knife struct {}
func (*Knife) UseWeapon() {
fmt.Println("使用匕首 去战斗")
}
//context 环境类
type Hero struct {
strategy WeaponStrategy
}
func (h *Hero) SetWeaponStrategy(s WeaponStrategy) {
h.strategy = s
}
func (h *Hero) Fight() {
h.strategy.UseWeapon() //调用策略
}
func main() {
hero := new(Hero)
hero.SetWeaponStrategy(new(Ak47))
hero.Fight()
hero.SetWeaponStrategy(new(Knife))
hero.Fight()
}优点：
- 策略模式提供了对“开闭原则”的完美支持，用户可以在不修改原有系统的基础上选择算法或行为，也可以灵活地增加新的算法或行为。
- 使用策略模式可以避免多重条件选择语句。多重条件选择语句不易维护，它把采取哪一种算法或行为的逻辑与算法或行为本身的实现逻辑混合在一起，将它们全部硬编码(Hard Coding)在一个庞大的多重条件选择语句中，比直接继承环境类的办法还要原始和落后。
- 策略模式提供了一种算法的复用机制。由于将算法单独提取出来封装在策略类中，因此不同的环境类可以方便地复用这些策略类。
缺点：
- 客户端必须知道所有的策略类，并自行决定使用哪一个策略类。这就意味着客户端必须理解这些算法的区别，以便适时选择恰当的算法。换言之，策略模式只适用于客户端知道所有的算法或行为的情况。
- 策略模式将造成系统产生很多具体策略类，任何细小的变化都将导致系统要增加一个新的具体策略类。
适用场景：
- 准备一组算法，并将每一个算法封装起来，使得它们可以互换。
4.观察者模式 #
观察者模式是用于建立一种对象与对象之间的依赖关系，一个对象发生改变时将自动通知其他对象，其他对象将相应作出反应。在观察者模式中，发生改变的对象称为观察目标，而被通知的对象称为观察者，一个观察目标可以对应多个观察者，而且这些观察者之间可以没有任何相互联系，可以根据需要增加和删除观察者，使得系统更易于扩展。观察者模式中的角色与职责如下：
- Subject（被观察者或目标，抽象主题）：被观察的对象，当需要被观察的状态发生变化时，需要通知队列中所有观察者对象。Subject需要维持（添加，删除，通知）一个观察者对象的队列列表。
- Observer（观察者）：接口或抽象类。当Subject的状态发生变化时，Observer对象将通过一个callback函数得到通知。
- ConcreteObserver（具体观察者）：观察者的具体实现。得到通知后将完成一些具体的业务逻辑处理。
package main
import "fmt"
//---------抽象层---------
//抽象的观察者
type Listener interface {
OnTeacherComing()
}
//通知者
type Notifier interface {
AddListener(listener Listener)
RemoveListener(listener Listener)
Notify()
}
//---------实现层---------
type StuZhang3 struct {
BadThing string
}
func (s *StuZhang3) OnTeacherComing() {
fmt.Println("张3停止 ", s.BadThing)
}
func (s *StuZhang3) DoBadThing() {
fmt.Println("张3 正在", s.BadThing)
}
type StuZhao4 struct {
BadThing string
}
func (s *StuZhao4) OnTeacherComing() {
fmt.Println("赵4停止 ", s.BadThing)
}
func (s *StuZhao4) DoBadThing() {
fmt.Println("赵4 正在", s.BadThing)
}
type StuWang5 struct {
BadThing string
}
func (s *StuWang5) OnTeacherComing() {
fmt.Println("王5停止 ", s.BadThing)
}
func (s *StuWang5) DoBadThing() {
fmt.Println("王5 正在", s.BadThing)
}
//通知者班长
type ClassMonitor struct {
Listeners []Listener
}
func (c *ClassMonitor) AddListener(listener Listener) {
c.Listeners = append(c.Listeners, listener)
}
func (c *ClassMonitor) RemoveListener(listener Listener) {
for i, l := range c.Listeners {
if l == listener {
c.Listeners = append(c.Listeners[:i], c.Listeners[i+1:]...)
return
}
}
}
func (c *ClassMonitor) Notify() {
for _, l := range c.Listeners {
//依次调用观察者的具体动作
l.OnTeacherComing()
}
}
func main() {
s1 := &StuZhang3{
BadThing: "抄作业",
}
s2 := &StuZhao4{
BadThing: "玩王者荣耀",
}
s3 := &StuWang5{
BadThing: "看赵四玩王者荣耀",
}
monitor := new(ClassMonitor)
fmt.Println("上课了，但是老师没有来，学生们都在忙自己的事...")
s1.DoBadThing()
s2.DoBadThing()
s3.DoBadThing()
monitor.AddListener(s1)
monitor.AddListener(s2)
monitor.AddListener(s3)
fmt.Println("这时候老师来了，班长给学生使了一个眼神...")
monitor.Notify()
}优点：
- 观察者模式可以实现表示层和数据逻辑层的分离，定义了稳定的消息更新传递机制，并抽象了更新接口，使得可以有各种各样不同的表示层充当具体观察者角色。
- 观察者模式在观察目标和观察者之间建立一个抽象的耦合。观察目标只需要维持一个抽象观察者的集合，无须了解其具体观察者。由于观察目标和观察者没有紧密地耦合在一起，因此它们可以属于不同的抽象化层次。
- 观察者模式支持广播通信，观察目标会向所有已注册的观察者对象发送通知，简化了一对多系统设计的难度。
- 观察者模式满足“开闭原则”的要求，增加新的具体观察者无须修改原有系统代码，在具体观察者与观察目标之间不存在关联关系的情况下，增加新的观察目标也很方便。
缺点：
- 如果一个观察目标对象有很多直接和间接观察者，将所有的观察者都通知到会花费很多时间。
- 如果在观察者和观察目标之间存在循环依赖，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。
- 观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。
适用场景：
- 一个抽象模型有两个方面，其中一个方面依赖于另一个方面，将这两个方面封装在独立的对象中使它们可以各自独立地改变和复用。
- 一个对象的改变将导致一个或多个其他对象也发生改变，而并不知道具体有多少对象将发生改变，也不知道这些对象是谁。
- 需要在系统中创建一个触发链，A对象的行为将影响B对象，B对象的行为将影响C对象……，可以使用观察者模式创建一种链式触发机制。