add singleton

singleton/README.md

@@ -0,0 +1,23 @@
+# Singleton
+あるクラスに対してインスタンスが１つだけ生成されるよう制限する
+
+### メリット
+* クラスのインスタンスが１つしか生成されない
+
+### デメリット
+* 本当に１つでいいのか？要件の変化を織り込んでない
+* ユニットテストの妨げになりがち
+  * mockに差しかえれない
+  * どのような順序でもテストが可能でないといけない
+* singletonを明示的に殺す方法はない
+* 複数のsingletonがある場合、どの順序でクリーンアップされるかは決まってない
+  * 依存関係上にあると...
+
+### ポイント
+* 必要なインスタンスが絶対に1つだけと確信したら使う
+* あとDIコンテナに実装してあげると依存関係気にしなくていいよね
+
+### 例題
+* 本の貸出しリスト
+* Ruby, Perlの本は貸出し中かどうか、貸出しリストが複数あったらわからないから
+* singletonパターンを使って、貸出しリストはこの1冊のみ と保証する

singleton/singleton.go

@@ -0,0 +1,34 @@
+package singleton
+
+import (
+	"fmt"
+	"sync"
+)
+
+type lendingList struct {
+	Books []Book
+}
+
+var lendingListInstance *lendingList
+var once sync.Once
+
+func GetLendingList() *lendingList {
+	once.Do(func() {
+		// 初期化
+		lendingListInstance = &lendingList{}
+	})
+	return lendingListInstance
+}
+
+type Book string
+
+func (l *lendingList) Lending(b Book) {
+	for _, v := range l.Books {
+		if v == b {
+			fmt.Printf("%v貸りられてるよ\n", b)
+			return
+		}
+	}
+	l.Books = append(l.Books, b)
+	fmt.Printf("%vを借りるね\n", b)
+}

singleton/singleton_test.go

@@ -0,0 +1,24 @@
+package singleton
+
+import "testing"
+
+func TestSingleton(t *testing.T) {
+	ch := make(chan interface{})
+	defer close(ch)
+
+	books := []Book{"ruby", "perl", "ruby"}
+
+	for _, b := range books {
+		go run(ch, b)
+	}
+
+	for i := 1; i <= len(books); i++ {
+		<-ch
+	}
+}
+
+func run(ch chan interface{}, b Book) {
+	s := GetLendingList()
+	ch <- s
+	s.Lending(b)
+}