Goでデザインパターンを学ぶよ

kiki_ki

参考

kiki_ki

生成パターン

Abstract Factory
Builder
Factory Method
Prototype
Singleton

kiki_ki

Abstract Factory

抽象的な工場と抽象的な部品を使って、抽象的な製品を作るパターン
clientが具体的な実装を考慮する必要が薄くなるというメリットがある、らしい。

上記リンクの画像でなんとなくイメージできる。

下記、諸々参考にさせていただきました :kansha:

ほぼほぼ写経で実装してみた。

clientはコンストラクタを呼ぶ際にfactoryのtypeを指定するだけで内部で処理を差し替えた実体を生成できるというやつ。なんとなく理解はできた気がするが、実務でこう綺麗に抽象化したコードを書ける自信はちょっとない...鍛錬である。

kiki_ki

Builder

builder(抽象)、director(実体)、concreateBuilder(builderの実体)の3役から成る。

実装

package builder

type builder interface {
  A() string
}

type Director struct {
	builder
}

func (d *Director) Construct() string {
	return d.A()
}

type ConcreateBuilder1 struct {}

func (c *ConcreateBuilder1) A() string {
	return "1"
}

type ConcreateBuilder2 struct {}

func (c *ConcreateBuilder2) A() string {
	return "2"
}

clientからの呼び出し

package builder

import (
	"testing"
)

func TestBuilder(t *testing.T) {
	t.Run("builder1", func(t *testing.T) {
		testBuilder(t, new(ConcreateBuilder1), "1")
	})
	t.Run("builder2", func(t *testing.T) {
		testBuilder(t, new(ConcreateBuilder2), "2")
	})
}

func testBuilder(t *testing.T, b builder, want string) {
	director := new(Director)
	director.builder = b
	result := director.Construct()
	if want != result {
		t.Errorf("want: %s, result: %s", want, result)
	}
}

builder in directorにしておくことで、共通処理をdirectorに実装できる。
builderの実体がdirectorのtypeになるイメージ？
意図せず使ってそう