Go 23种设计模式

本文介绍: 抽象工厂模式基于工厂方法模式。两者的区别在于：工厂方法模式是创建出一种产品，而抽象工厂模式是创建出一类产品。这二种都属于工厂模式，在设计上是相似的。假设，有一个存储工厂，提供redis和mysql两种存储数据的方式。如果使用工厂方法模式，我们就需要一个存储工厂，并提供Sav eRedi s方法和Sav eMy sql方法。如果此时业务还需要分成存储散文和古诗两种载体，这两种载体都可以进行redis和mysql 存储。

结构型模式

结构型模式将一些对象和类组装成更大的结构体，并同时保持结构的灵活和高效。

适配器模式 Adapter

问题

适配器模式说白了就是兼容。

假设一开始我们提供了A对象，后期随着业务迭代，又需要从A对象的基础之上衍生出不同的需求。如果有很多函数已经在线上调用了A对象，此时再对A对象进行修改就比较麻烦，因为需要考虑兼容问题。还有更糟糕的情况，你可能没有程序库的源代码，从而无法对其进行修改。

此时就可以用一个适配器，它就像一个接口转换器，调用方只需要调用这个适配器接口，而不需要关注其背后的实现，由适配器接口封装复杂的过程。

解决

假设有2个接口，一个将厘米转为米，一个将米转为厘米。我们提供一个适配器接口，使调用方不需要再操心调用哪个接口，直接由适配器做好兼容。

请看以下代码：

package adapter

// 提供一个获取米的接口和一个获取厘米的接口

type Cm interface {
  getLength(float64) float64
}

type M interface {
  getLength(float64) float64
}

func NewM() M {
  return &getLengthM{}
}

type getLengthM struct{}

func (*getLengthM) getLength(cm float64) float64 {
  return cm / 10
}

func NewCm() Cm {
  return &getLengthCm{}
}

type getLengthCm struct{}

func (a *getLengthCm) getLength(m float64) float64 {
  return m * 10
}

// 适配器

type LengthAdapter interface {
  getLength(string, float64) float64
}

func NewLengthAdapter() LengthAdapter {
  return &getLengthAdapter{}
}

type getLengthAdapter struct{}

func (*getLengthAdapter) getLength(isType string, into float64) float64 {
  if isType == "m" {
    return NewM().getLength(into)
  }
  return NewCm().getLength(into)
}

上面实现了Cm和M两个接口，并由适配器LengthAdapter做兼容。

测试代码：

package adapter

import "testing"

func TestAdapter(t *testing.T) {
  into := 10.5
  getLengthAdapter := NewLengthAdapter().getLength("m", into)
  getLengthM := NewM().getLength(into)
  if getLengthAdapter != getLengthM {
    t.Fatalf("getLengthAdapter: %f, getLengthM: %f", getLengthAdapter, getLengthM)
  }
}

桥接模式Bridge

问题

假设一开始业务需要两种发送信息的渠道，sms和email，我们可以分别实现sms和email两个接口。

之后随着业务迭代，又产生了新的需求，需要提供两种系统发送方式，systemA和systemB，并且这两种系统发送方式都应该支持 sms和email渠道。

此时至少需要提供4种方法：systemA to sms，systemA to email，systemB to sms，systemB to email。

如果再分别增加一种渠道和一种系统发送方式，就需要提供9种方法。这将导致代码的复杂程度指数增长。

对象树模式Object Tree

问题

在项目中，如果我们需要用到树状结构，就可以使用对象树模式。换言之，如果项目的核心模型不能以树状结构表示，则没必要使用对象树模式。

对象树模式的用处就在于可以利用多态和递归机制更方便地使用复杂树结构。

解决

请看以下代码：

package objecttree

import "fmt"

type Component interface {
  Parent() Component
  SetParent(Component)
  Name() string
  SetName(string)
  AddChild(Component)
  Search(string)
}

const (
  LeafNode = iota
  CompositeNode
)

func NewComponent(kind int, name string) Component {
  var c Component
  switch kind {
  case LeafNode:
    c = NewLeaf()
  case CompositeNode:
    c = NewComposite()
  }

  c.SetName(name)
  return c
}

type component struct {
  parent Component
  name   string
}

func (c *component) Parent() Component {
  return c.parent
}

func (c *component) SetParent(parent Component) {
  c.parent = parent
}

func (c *component) Name() string {
  return c.name
}

func (c *component) SetName(name string) {
  c.name = name
}

func (c *component) AddChild(Component) {}

type Leaf struct {
  component
}

func NewLeaf() *Leaf {
  return &Leaf{}
}

func (c *Leaf) Search(pre string) {
  fmt.Printf("leaf %s-%sn", pre, c.Name())
}

type Composite struct {
  component
  childs []Component
}

func NewComposite() *Composite {
  return &Composite{
    childs: make([]Component, 0),
  }
}

func (c *Composite) AddChild(child Component) {
  child.SetParent(c)
  c.childs = append(c.childs, child)
}

func (c *Composite) Search(pre string) {
  fmt.Printf("%s+%sn", pre, c.Name())
  pre += " "
  for _, comp := range c.childs {
    comp.Search(pre)
  }
}

在Search方法中使用递归打印出了整棵树结构。

测试代码：

package objecttree

func ExampleComposite() {
  root := NewComponent(CompositeNode, "root")
  c1 := NewComponent(CompositeNode, "c1")
  c2 := NewComponent(CompositeNode, "c2")
  c3 := NewComponent(CompositeNode, "c3")

  l1 := NewComponent(LeafNode, "l1")
  l2 := NewComponent(LeafNode, "l2")
  l3 := NewComponent(LeafNode, "l3")

  root.AddChild(c1)
  root.AddChild(c2)
  c1.AddChild(c3)
  c1.AddChild(l1)
  c2.AddChild(l2)
  c2.AddChild(l3)

  root.Search("")
  // Output:
  // +root
  //  +c1
  //   +c3
  //leaf   -l1
  //  +c2
  //leaf   -l2
  //leaf   -l3
}

装饰模式Dec orator

问题

有时候我们需要在一个类的基础上扩展另一个类，例如，一个披萨类，你可以在披萨类的基础上增加番茄披萨类和芝士披萨类。此时就可以使用装饰模式，简单来说，装饰模式就是将对象封装到另一个对象中，用以为原对象绑定新的行为。

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

解决

用上文的披萨类做例子。请看以下代码：

package decorator

type pizza interface {
  getPrice() int
}

type base struct {}

func (p *base) getPrice() int {
  return 15
}

type tomatoTopping struct {
  pizza pizza
}

func (c *tomatoTopping) getPrice() int {
  pizzaPrice := c.pizza.getPrice()
  return pizzaPrice + 10
}

type cheeseTopping struct {
  pizza pizza
}

func (c *cheeseTopping) getPrice() int {
  pizzaPrice := c.pizza.getPrice()
  return pizzaPrice + 20
}

首先我们定义了pizza接口，创建了base类，实现了方法getPrice。然后再用装饰模式的理念，实现了tomatoTop ping和cheeseTopping类，他们都封装了pizza接口的getPrice方法。

测试代码：

package decorator

import "fmt"

func ExampleDecorator() {

  pizza := &base{}

  //Add cheese topping
  pizzaWithCheese := &cheeseTopping{
    pizza: pizza,
  }

  //Add tomato topping
  pizzaWithCheeseAndTomato := &tomatoTopping{
    pizza: pizzaWithCheese,
  }

  fmt.Printf("price is %dn", pizzaWithCheeseAndTomato.getPrice())

  // Output:
  // price is 45
}

外观模式Facade

问题

如果你需要初始化大量复杂的库或框架，就需要管理其依赖关系并且按正确的顺序执行。此时就可以用一个外观类来统一处理这些依赖关系，以对其进行整合。

解决

外观模式和建造者模式很相似。两者的区别在于，外观模式是一种结构型模式，她的目的是将对象组合起来，而不是像建造者模式那样创建出不同的产品。

请看以下代码：

package facade

import "fmt"

// 初始化APIA和APIB

type APIA interface {
  TestA() string
}

func NewAPIA() APIA {
  return &apiRunA{}
}

type apiRunA struct{}

func (*apiRunA) TestA() string {
  return "A api running"
}

type APIB interface {
  TestB() string
}

func NewAPIB() APIB {
  return &apiRunB{}
}

type apiRunB struct{}

func (*apiRunB) TestB() string {
  return "B api running"
}

// 外观类

type API interface {
  Test() string
}

func NewAPI() API {
  return &apiRun{
    a: NewAPIA(),
    b: NewAPIB(),
  }
}

type apiRun struct {
  a APIA
  b APIB
}

func (a *apiRun) Test() string {
  aRet := a.a.TestA()
  bRet := a.b.TestB()
  return fmt.Sprintf("%sn%s", aRet, bRet)
}

假设要初始化APIA和APIB，我们就可以通过一个外观类API进行处理，在外观类接口Test方法中分别执行类TestA方法和TestB方法。

测试代码：

package facade

import "testing"

var expect = "A api runningnB api running"

// TestFacadeAPI ...
func TestFacadeAPI(t *testing.T) {
  api := NewAPI()
  ret := api.Test()
  if ret != expect {
    t.Fatalf("expect %s, return %s", expect, ret)
  }
}

代理模式Proxy

问题

如果你需要在访问一个对象时，有一个像“代理”一样的角色，她可以在访问对象之前为你进行缓存检查、权限判断等访问控制，在访问对象之后为你进行结果缓存、日志记录等结果处理，那么就可以考虑使用代理模式。

回忆一下一些web 框架的router 模块，当客户端访问一个接口时，在最终执行对应的接口之前，router 模块会执行一些事前操作，进行权限判断等操作，在执行之后还会记录日志，这就是典型的代理模式。

解决

代理模式需要一个代理类，其包含执行真实对象所需的成员变量，并由代理类管理整个生命周期。

请看以下代码：

package proxy

import "fmt"

type Subject interface {
  Proxy() string
}

// 代理

type Proxy struct {
  real RealSubject
}

func (p Proxy) Proxy() string {
  var res string

  // 在调用真实对象之前，检查缓存，判断权限，等等
  p.real.Pre()

  // 调用真实对象
  p.real.Real()

  // 调用之后的操作，如缓存结果，对结果进行处理，等等
  p.real.After()

  return res
}

// 真实对象

type RealSubject struct{}

func (RealSubject) Real() {
  fmt.Print("real")
}

func (RealSubject) Pre() {
  fmt.Print("pre:")
}

func (RealSubject) After() {
  fmt.Print(":after")
}

我们定义了代理类Proxy，执行Proxy之后，在调用真实对象Real之前，我们会先调用事前对象Pre，并在执行真实对象Real之后，调用事后对象After。

测试代码：

package proxy

func ExampleProxy() {
  var sub Subject
  sub = &Proxy{}
  sub.Proxy()

  // Output:
  // pre:real:after
}

行为型模式

行为型模式处理对象和类之间的通信，并使其保持高效的沟通和委派。

责任链模式Chain of Responsi bi lity

问题

假设我们要让程序按照指定的步骤执行，并且这个步骤的顺序不是固定的，而是可以根据不同需求改变的，每个步骤都会对请求进行一些处理，并将结果传递给下一个步骤的处理者，就像一条流水线一样，我们该如何实现？

当遇到这种必须按顺序执行多个处理者，并且处理者的顺序可以改变的需求，我们可以考虑使用责任链模式。

解决

责任链模式使用了类似链表的结构。请看以下代码：

package chain

import "fmt"

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

type aPart struct {
  next department
}

func (r *aPart) execute(p *Do) {
  if p.aPartDone {
    fmt.Println("aPart done")
    r.next.execute(p)
    return
  }
  fmt.Println("aPart")
  p.aPartDone = true
  r.next.execute(p)
}

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

type bPart struct {
  next department
}

func (d *bPart) execute(p *Do) {
  if p.bPartDone {
    fmt.Println("bPart done")
    d.next.execute(p)
    return
  }
  fmt.Println("bPart")
  p.bPartDone = true
  d.next.execute(p)
}

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

type endPart struct {
  next department
}

func (c *endPart) execute(p *Do) {
  if p.endPartDone {
    fmt.Println("endPart Done")
  }
  fmt.Println("endPart")
}

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

type Do struct {
  aPartDone   bool
  bPartDone   bool
  endPartDone bool
}

我们实现了方法execute和setNext，并定义了aPart、bPart、endPart这3个处理者，每个处理者都可以通过 execute方法执行其对应的业务代码，并可以通过 setNext方法决定下一个处理者是谁。除了endPart是最终的处理者之外，在它之前的处理者aPart、bPart的顺序都可以任意调整。

请看以下测试代码：

func ExampleChain() {
  startPart := &endPart{}

  aPart := &aPart{}
  aPart.setNext(startPart)

  bPart := &bPart{}
  bPart.setNext(aPart)

  do := &Do{}
  bPart.execute(do)

  // Output:
  // bPart
  // aPart
  // endPart
}

我们也可以调整处理者的执行顺序：

func ExampleChain2() {
  startPart := &endPart{}

  bPart := &bPart{}
  bPart.setNext(startPart)

  aPart := &aPart{}
  aPart.setNext(bPart)

  do := &Do{}
  aPart.execute(do)

  // Output:
  // aPart
  // bPart
  // endPart
}

命令模式Comm and

问题

假设你实现了开启和关闭电视机的功能，随着业务迭代，还需要实现开启和关闭冰箱的功能，开启和关闭电灯的功能，开启和关闭微波炉的功能……这些功能都基于你的基类，开启和关闭。如果你之后对基类进行修改，很可能会影响到其他功能，这使项目变得不稳定了。

一个优秀的设计往往会关注于软件的分层与解耦，命令模式试图做到这样的结果：让命令和对应功能解耦，并能根据不同的请求将其方法参数化。

解决

还是用开启和关闭家用电器的例子来举例吧。请看以下代码：

package command

import "fmt"

// 请求者

type button struct {
  command command
}

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

// 具体命令接口

type command interface {
  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{}

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

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

type airConditioner struct{}

func (t *airConditioner) on() {
  fmt.Println("Turning air conditioner on")
}

func (t *airConditioner) off() {
  fmt.Println("Turning air conditioner off")
}

我们分别实现了请求者button，命令接口command，接收者 device。请求者button就像是那个可以执行开启或关闭的遥控器，命令接口command则是一个中间层，它使我们的请求者和接收者解藕。

测试代码：

package command

func ExampleCommand() {
  Tv()
  AirConditioner()

  // Output:
  // Turning tv on
  // Turning tv off
  // Turning air conditioner on
  // Turning air conditioner off
}

func Tv() {
  tv := &tv{}

  onTvCommand := &onCommand{
    device: tv,
  }

  offTvCommand := &offCommand{
    device: tv,
  }

  onTvButton := &button{
    command: onTvCommand,
  }
  onTvButton.press()

  offTvButton := &button{
    command: offTvCommand,
  }
  offTvButton.press()
}

func AirConditioner() {
  airConditioner := &airConditioner{}

  onAirConditionerCommand := &onCommand{
    device: airConditioner,
  }

  offAirConditionerCommand := &offCommand{
    device: airConditioner,
  }

  onAirConditionerButton := &button{
    command: onAirConditionerCommand,
  }
  onAirConditionerButton.press()

  offAirConditionerButton := &button{
    command: offAirConditionerCommand,
  }
  offAirConditionerButton.press()
}

迭代器模式Iterator

问题

迭代器模式用于遍历集合中的元素，无论集合的数据结构是怎样的。

解决

请看以下代码：

package iterator

// 集合接口

type collection interface {
  createIterator() iterator
}

// 具体的集合

type part struct {
  title  string
  number int
}

type partCollection struct {
  part
  parts []*part
}

func (u *partCollection) createIterator() iterator {
  return &partIterator{
    parts: u.parts,
  }
}

// 迭代器

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

// 具体的迭代器

type partIterator struct {
  index int
  parts []*part
}

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

}
func (u *partIterator) getNext() *part {
  if u.hasNext() {
    part := u.parts[u.index]
    u.index++
    return part
  }
  return nil
}

测试代码：

func ExampleIterator() {
  part1 := &part{
    title:  "part1",
    number: 10,
  }
  part2 := &part{
    title:  "part2",
    number: 20,
  }
  part3 := &part{
    title:  "part3",
    number: 30,
  }

  partCollection := &partCollection{
    parts: []*part{part1, part2, part3},
  }

  iterator := partCollection.createIterator()

  for iterator.hasNext() {
    part := iterator.getNext()
    fmt.Println(part)
  }

  // Output:
  // &{part1 10}
  // &{part2 20}
  // &{part3 30}
}

中介者模式Mediator

问题

中介者模式试图解决网状关系的复杂关联，降低对象间的耦合度。

举个例子，假设一个十字路口上的车都是对象，它们会执行不同的操作，前往不同的目的地，那么在十字路口指挥的交警就是“中介者”。

各个对象通过执行中介者接口，再由中介者维护对象之间的联系。这能使对象变得更独立，比较适合用在一些对象是网状关系的案例上。

解决

假设有p1，p2，p3这3个发送者，p1 发送的消息p2能收到，p2 发送的消息p1能收到，p3 发送的消息则p1和p2能收到，如何实现呢？像这种情况就很适合用中介者模式实现。

请看以下代码：

package mediator

import (
  "fmt"
)

type p1 struct{}

func (p *p1) getMessage(data string) {
  fmt.Println("p1 get message: " + data)
}

type p2 struct{}

func (p *p2) getMessage(data string) {
  fmt.Println("p2 get message: " + data)
}

type p3 struct{}

func (p *p3) getMessage(data string) {
  fmt.Println("p3 get message: " + data)
}

type Message struct {
  p1 *p1
  p2 *p2
  p3 *p3
}

func (m *Message) sendMessage(i interface{}, data string) {
  switch i.(type) {
  case *p1:
    m.p2.getMessage(data)
  case *p2:
    m.p1.getMessage(data)
  case *p3:
    m.p1.getMessage(data)
    m.p2.getMessage(data)
  }
}

我们定义了p1，p2，p3这3个对象，然后实现了中介者sendMessage。

测试代码：

package mediator

func ExampleMediator() {
  message := &Message{}

  p1 := &p1{}
  p2 := &p2{}
  p3 := &p3{}

  message.sendMessage(p1, "hi! my name is p1")
  message.sendMessage(p2, "hi! my name is p2")
  message.sendMessage(p3, "hi! my name is p3")

  // Output:
  // p2 get message: hi! my name is p1
  // p1 get message: hi! my name is p2
  // p1 get message: hi! my name is p3
  // p2 get message: hi! my name is p3
}

备忘录模式Memento

问题

常用的文字编辑器都支持保存和恢复一段文字的操作，如果我们想要在程序中实现保存和恢复的功能该怎么做呢？

我们需要提供保存和恢复的功能，当保存功能被调用时，就会生成当前对象的快照，在恢复功能被调用时，就会用之前保存的快照覆盖当前的快照。这可以使用备忘录模式来做。

解决

请看以下代码：

package memento

import "fmt"

type Memento interface{}

type Text struct {
  content string
}

type textMemento struct {
  content string
}

func (t *Text) Write(content string) {
  t.content = content
}

func (t *Text) Save() Memento {
  return &textMemento{
    content: t.content,
  }
}

func (t *Text) Load(m Memento) {
  tm := m.(*textMemento)
  t.content = tm.content
}

func (t *Text) Show() {
  fmt.Println("content:", t.content)
}

我们定义了textMemento结构体用于保存当前快照，并在Load方法中将快照覆盖到当前内容。

测试代码：

package memento

func ExampleText() {
  text := &Text{
    content: "how are you",
  }

  text.Show()
  progress := text.Save()

  text.Write("fine think you and you")
  text.Show()

  text.Load(progress)
  text.Show()

  // Output:
  // content: how are you
  // content: fine think you and you
  // content: how are you
}

观察者模式Observer

问题

如果你需要在一个对象的状态被改变时，其他对象能作为其“观察者”而被通知，就可以使用观察者模式。

我们将自身的状态改变就会通知给其他对象的对象称为“发布者”，关注发布者状态变化的对象则称为“订阅者”。

解决

请看以下代码：

package observer

import "fmt"

// 发布者

type Subject struct {
  observers []Observer
  content   string
}

func NewSubject() *Subject {
  return &Subject{
    observers: make([]Observer, 0),
  }
}

// 添加订阅者

func (s *Subject) AddObserver(o Observer) {
  s.observers = append(s.observers, o)
}

// 改变发布者的状态

func (s *Subject) UpdateContext(content string) {
  s.content = content
  s.notify()
}

// 通知订阅者接口

type Observer interface {
  Do(*Subject)
}

func (s *Subject) notify() {
  for _, o := range s.observers {
    o.Do(s)
  }
}

// 订阅者

type Reader struct {
  name string
}

func NewReader(name string) *Reader {
  return &Reader{
    name: name,
  }
}

func (r *Reader) Do(s *Subject) {
  fmt.Println(r.name + " get " + s.content)
}

很简单，我们只要实现一个通知 notify方法，在发布者的状态改变时执行即可。

测试代码：

package observer

func ExampleObserver() {
  subject := NewSubject()

  boy := NewReader("小明")
  girl := NewReader("小美")

  subject.AddObserver(boy)
  subject.AddObserver(girl)

  subject.UpdateContext("hi~")

  // Output:
  // 小明 get hi~
  // 小美 get hi~
}

状态模式 State

问题

如果一个对象的实现方法会根据自身的状态而改变，就可以使用状态模式。

举个例子：假设有一个开门的方法，门的状态在一开始是“关闭”，你可以执行open方法和close方法，当你执行了open方法，门的状态就变成了“开启”，再执行open方法就不会执行开门的功能，而是返回“门已开启”，如果执行close方法，门的状态就变成了“关闭”，再执行close方法就不会执行关门的功能，而是返回“门已关闭”。这是一个简单的例子，我们将为每个状态提供不同的实现方法，将这些方法组织起来很麻烦，如果状态也越来越多呢？无疑，这将会使代码变得臃肿。

解决

如果我们需要为一个门对象提供3种状态下的open和close方法：

“开启”状态下，open方法返回“门已开启”，close方法返回“关闭成功”。
“关闭”状态下，open方法返回“开启成功”，close方法返回“门已关闭”。
“损坏”状态下，open方法返回“门已损坏，无法开启”，close方法返回“门已损坏，无法关闭”。

请看以下代码：

package state

import "fmt"

// 不同状态需要实现的接口

type state interface {
  open(*door)
  close(*door)
}

// 门对象

type door struct {
  opened  state
  closed  state
  damaged state

  currentState state // 当前状态
}

func (d *door) open() {
  d.currentState.open(d)
}

func (d *door) close() {
  d.currentState.close(d)
}

func (d *door) setState(s state) {
  d.currentState = s
}

// 开启状态

type opened struct{}

func (o *opened) open(d *door) {
  fmt.Println("门已开启")
}

func (o *opened) close(d *door) {
  fmt.Println("关闭成功")
}

// 关闭状态

type closed struct{}

func (c *closed) open(d *door) {
  fmt.Println("开启成功")
}

func (c *closed) close(d *door) {
  fmt.Println("门已关闭")
}

// 损坏状态

type damaged struct{}

func (a *damaged) open(d *door) {
  fmt.Println("门已损坏，无法开启")
}

func (a *damaged) close(d *door) {
  fmt.Println("门已损坏，无法关闭")
}

我们的门对象door实现了open和close方法，在方法中，只需要调用当前状态currentState的open和close方法即可。

测试代码：

package state

func ExampleState() {
  door := &door{}

  // 开启状态
  opened := &opened{}
  door.setState(opened)
  door.open()
  door.close()

  // 关闭状态
  closed := &closed{}
  door.setState(closed)
  door.open()
  door.close()

  // 损坏状态
  damaged := &damaged{}
  door.setState(damaged)
  door.open()
  door.close()

  // Output:
  // 门已开启
  // 关闭成功
  // 开启成功
  // 门已关闭
  // 门已损坏，无法开启
  // 门已损坏，无法关闭
}

策略模式Strategy

问题

假设需要实现一组出行的功能，出现的方案可以选择步行、骑行、开车，最简单的做法就是分别实现这3种方法供客户端调用。但这样做就使对象与其代码实现变得耦合了，客户端需要决定出行方式，然后决定调用步行出行、骑行出行、开车出行等方法，这不符合开闭原则。

而策略模式的区别在于，它会将这些出行方案抽取到一组被称为策略的类中，客户端还是调用同一个出行对象，不需要关注实现细节，只需要在参数中指定所需的策略即可。

解决

请看以下代码：

package strategy

import "fmt"

type Travel struct {
  name     string
  strategy Strategy
}

func NewTravel(name string, strategy Strategy) *Travel {
  return &Travel{
    name:     name,
    strategy: strategy,
  }
}

func (p *Travel) traffic() {
  p.strategy.traffic(p)
}

type Strategy interface {
  traffic(*Travel)
}

type Walk struct{}

func (w *Walk) traffic(t *Travel) {
  fmt.Println(t.name + " walk")
}

type Ride struct{}

func (w *Ride) traffic(t *Travel) {
  fmt.Println(t.name + " ride")
}

type Drive struct{}

func (w *Drive) traffic(t *Travel) {
  fmt.Println(t.name + " drive")
}

我们定义了strategy一组策略接口，为其实现了Walk、Ride、Drive算法。客户端只需要执行traffic方法即可，无需关注实现细节。

测试代码：

package strategy

func ExampleTravel() {
  walk := &Walk{}
  Travel1 := NewTravel("小明", walk)
  Travel1.traffic()

  ride := &Ride{}
  Travel2 := NewTravel("小美", ride)
  Travel2.traffic()

  drive := &Drive{}
  Travel3 := NewTravel("小刚", drive)
  Travel3.traffic()

  // Output:
  // 小明 walk
  // 小美 ride
  // 小刚 drive
}

模板方法模式Template Method

问题

模板方法模式就是将算法分解为一系列步骤，然后在一个模版方法中依次调用这些步骤。这样客户端就不需要了解各个步骤的实现细节，只需要调用模版即可。

解决

一个非常简单的例子，请看以下代码：

package templatemethod

import "fmt"

type PrintTemplate interface {
  Print(name string)
}

type template struct {
  isTemplate PrintTemplate
  name       string
}

func (t *template) Print() {
  t.isTemplate.Print(t.name)
}

type A struct{}

func (a *A) Print(name string) {
  fmt.Println("a: " + name)
  // 业务代码……
}

type B struct{}

func (b *B) Print(name string) {
  fmt.Println("b: " + name)
  // 业务代码……
}

测试代码：

package templatemethod

func ExamplePrintTemplate() {
  templateA := &A{}
  template := &template{
    isTemplate: templateA,
    name:       "hi~",
  }
  template.Print()

  templateB := &B{}
  template.isTemplate = templateB
  template.Print()

  // Output:
  // a: hi~
  // b: hi~
}

访问者模式Visitor

问题

访问者模式试图解决这样一个问题：在不改变类的对象结构的前提下增加新的操作。

解决

请看以下代码：

package visitor

import "fmt"

type Shape interface {
  accept(visitor)
}

type square struct{}

func (s *square) accept(v visitor) {
  v.visitForSquare(s)
}

type circle struct{}

func (c *circle) accept(v visitor) {
  v.visitForCircle(c)
}

type visitor interface {
  visitForSquare(*square)
  visitForCircle(*circle)
}

type sideCalculator struct{}

func (a *sideCalculator) visitForSquare(s *square) {
  fmt.Println("square side")
}

func (a *sideCalculator) visitForCircle(s *circle) {
  fmt.Println("circle side")
}

type radiusCalculator struct{}

func (a *radiusCalculator) visitForSquare(s *square) {
  fmt.Println("square radius")
}

func (a *radiusCalculator) visitForCircle(c *circle) {
  fmt.Println("circle radius")
}

测试代码：

package visitor

func ExampleShape() {
  square := &square{}
  circle := &circle{}

  side := &sideCalculator{}

  square.accept(side)
  circle.accept(side)

  radius := &radiusCalculator{}
  square.accept(radius)
  circle.accept(radius)

  // Output:
  // square side
  // circle side
  // square radius
  // circle radius
}

设计模式的“道”

上面那么多种设计模式你能记住几种呢？设计模式分为“术”的部分和“道”的部分，上面那些设计模式就是“术”的部分，他们是一些围绕着设计模式核心思路的经典解决方案。换句话说，重要的是理解为什么要用那些设计模式，具体问题，具体分析，而不是把某种设计模式生搬硬套进代码。

设计模式有6大原则，以上的设计模式目的就是为了使软件系统能达到这些原则：

开闭原则

软件应该对扩展开放，对修改关闭。

对系统进行扩展，而无需修改现有的代码。这可以降低软件的维护成本，同时也增加可扩展性。

里氏替换原则

任何基类可以出现的地方，子类一定可以出现。

里氏替换原则是对开闭原则的补充，实现开闭原则的关键步骤就是抽象化，基类与子类的关系就是要尽可能的抽象化。

依赖倒置原则

面向接口编程，抽象不应该依赖于具体类，具体类应当依赖于抽象。

这是为了减少类间的耦合，使系统更适宜于扩展，也更便于维护。

单一职责原则

一个类应该只有一个发生变化的原因。

一个类承载的越多，耦合度就越高。如果类的职责单一，就可以降低出错的风险，也可以提高代码的可读性。

最少知道原则

一个实体应当尽量少地与其他实体之间发生相互作用。

还是为了降低耦合，一个类与其他类的关联越少，越易于扩展。

接口分离原则

使用多个专门的接口，而不使用高耦合的单一接口。

避免同一个接口占用过多的职责，更明确的划分，可以降低耦合。高耦合会导致程序不易扩展，提高出错的风险。

原文地址:https://blog.csdn.net/Klaus_S/article/details/130615962

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。

如若转载，请注明出处：http://www.7code.cn/show_34970.html

如若内容造成侵权/违法违规/事实不符，请联系代码007邮箱：suwngjj01@126.com进行投诉反馈，一经查实，立即删除！

声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。

存储工厂模式

创建型模式

工厂方法模式 Factory Method

抽象工厂模式 Abstract Factory

建造者模式 Builder

原型模式 Prototype

单例模式 Singleton

结构型模式

适配器模式 Adapter

桥接模式Bridge

问题

对象树模式Object Tree

问题

解决

装饰模式Decorator

问题

解决

外观模式Facade

问题

解决

享元模式 Flyweight

问题

解决

代理模式Proxy

问题

解决

行为型模式

责任链模式Chain of Responsibility

问题

解决

命令模式Command

问题

解决

迭代器模式Iterator

问题

解决

中介者模式Mediator

问题

解决

备忘录模式Memento

问题

解决

观察者模式Observer

问题

解决

状态模式 State

问题

解决

策略模式Strategy

问题

解决

模板方法模式Template Method

问题

解决

访问者模式Visitor

问题

解决

设计模式的“道”

开闭原则

里氏替换原则

依赖倒置原则

单一职责原则

最少知道原则

接口分离原则

相关文章

发表回复 取消回复

工厂方法模式 Factor y Meth od

抽象工厂模式 Abstract Facto ry

建造者模式 Bui lder

单例模式 Singlet on

装饰模式Dec orator

责任链模式Chain of Responsi bi lity

命令模式Comm and

发表回复取消回复