Day 2: イディオマティックGo - 解説

本日のまとめ

イディオマティックGoの重要ポイント：

---

なぜイディオマティックGoが重要か

プロダクション環境での実例

Google での採用事例

Uber の Go Style Guide

• コードレビュー時間が40%短縮
• 新入社員のオンボーディング期間が30%短縮
• バグ発見率が25%向上

参考: Uber Go Style Guide

1. コードの一貫性

// チーム全員が同じスタイルで書く
// → レビューが楽、理解が早い

// 悪い例：人によってスタイルが違う
func get_user_name(u *User) string { ... }  // Aさん
func GetUserName(u *User) string { ... }    // Bさん
func (u *User) name() string { ... }        // Cさん

// 良い例：全員が同じスタイル
func (u *User) Name() string { ... }

2. ツールとの統合

# gofmtで自動フォーマット
go fmt ./...

# govetで静的解析
go vet ./...

# golintでスタイルチェック
golint ./...

これらのツールはイディオマティックGoを前提に設計されています。

---

オプションパターンの詳細

なぜオプションパターンを使うのか

// 問題：引数が増えると読みにくい
func NewClient(host string, port int, timeout time.Duration,
               maxRetries int, logger *Logger, cache *Cache) *Client

// 呼び出し側も意味がわからない
client := NewClient("localhost", 8080, 30*time.Second, 3, nil, nil)

// オプションパターンなら
client := NewClient(
    WithHost("localhost"),
    WithPort(8080),
    WithTimeout(30 * time.Second),
)
// 引数の意味が明確！

オプションパターンのバリエーション

// 1. 関数オプション（今回学んだ方法）
type Option func(*Client)

// 2. ビルダーパターン
client := NewClientBuilder().
    WithHost("localhost").
    WithPort(8080).
    Build()

// 3. 設定構造体
type Config struct {
    Host    string
    Port    int
    Timeout time.Duration
}

func NewClient(cfg Config) *Client

---

defer の高度な使い方

トランザクション管理

func executeInTransaction(db *sql.DB) error {
    tx, err := db.Begin()
    if err != nil {
        return err
    }

    // 成功時はコミット、失敗時はロールバック
    defer func() {
        if p := recover(); p != nil {
            tx.Rollback()
            panic(p) // re-panic
        } else if err != nil {
            tx.Rollback()
        } else {
            tx.Commit()
        }
    }()

    // トランザクション内の処理
    if err = step1(tx); err != nil {
        return err
    }
    if err = step2(tx); err != nil {
        return err
    }

    return nil
}

計測

func measureTime(name string) func() {
    start := time.Now()
    return func() {
        fmt.Printf("%s took %v\n", name, time.Since(start))
    }
}

func slowFunction() {
    defer measureTime("slowFunction")()

    time.Sleep(time.Second)
}

---

インターフェースの設計原則

Interface Segregation Principle（インターフェース分離の原則）

// 悪い例：巨大なインターフェース
type Repository interface {
    GetUser(id int) (*User, error)
    CreateUser(user *User) error
    UpdateUser(user *User) error
    DeleteUser(id int) error
    GetAllUsers() ([]*User, error)
    SearchUsers(query string) ([]*User, error)
    // ...さらに多くのメソッド
}

// 良い例：必要なものだけを要求
type UserGetter interface {
    GetUser(id int) (*User, error)
}

func GetUserHandler(getter UserGetter) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        // getterはGetUserだけ使える
        // テストも簡単
    }
}

Accept interfaces, return structs

// 良い例
func ProcessData(r io.Reader) (*Result, error) {
    // インターフェースを受け取る → テスト可能
    // 具象型を返す → 呼び出し側の柔軟性
}

// テスト時
func TestProcessData(t *testing.T) {
    input := strings.NewReader("test data")  // io.Readerを満たす
    result, err := ProcessData(input)
    // ...
}

---

よくある間違いと対策

1. シャドーイングの罠

// 危険なコード
err := firstOperation()
if err != nil {
    return err
}

if condition {
    result, err := secondOperation()  // errをシャドーイング
    if err != nil {
        return err
    }
    // ...
}

// ここで firstOperation のエラーに戻る！

// 対策：明示的に代入
err := firstOperation()
if err != nil {
    return err
}

if condition {
    var result *Result
    result, err = secondOperation()  // 既存のerrに代入
    if err != nil {
        return err
    }
    // ...
}

2. defer内のエラー処理

// 悪い例：deferのエラーを無視
func writeFile(filename string, data []byte) error {
    f, err := os.Create(filename)
    if err != nil {
        return err
    }
    defer f.Close()  // Close()のエラーは無視される

    _, err = f.Write(data)
    return err
}

// 良い例：名前付き戻り値でdeferのエラーも処理
func writeFile(filename string, data []byte) (err error) {
    f, err := os.Create(filename)
    if err != nil {
        return err
    }
    defer func() {
        if cerr := f.Close(); err == nil {
            err = cerr
        }
    }()

    _, err = f.Write(data)
    return err
}

---

メンタルモデル：イディオマティックGoの思考法

1. シンプルさを追求する（KISS原則）

Goの設計哲学は「Less is more」です。複雑な抽象化よりも、 読みやすく理解しやすいコードを優先します。

// 複雑な抽象化（避けるべき）
type AbstractFactoryStrategyBuilder interface {
    CreateFactoryWithStrategy(strategy Strategy) Factory
}

// シンプルな実装（推奨）
func NewClient(url string) *Client {
    return &Client{url: url}
}

2. 「見える」コードを書く

Goでは、暗黙的な動作よりも明示的なコードが好まれます。

// 暗黙的（Java風）
class User {
    @Autowired
    private Database db;  // DIコンテナによる自動注入
}

// 明示的（Go風）
type User struct {
    db Database
}

func NewUser(db Database) *User {
    return &User{db: db}  // 依存性が明確
}

3. エラーは値として扱う

Goでは、エラーは例外ではなく通常の値です。この考え方により、 エラーハンドリングが明示的になり、予期しない動作を防ぎます。

// エラーを値として扱う
result, err := operation()
if err != nil {
    // エラーハンドリングは呼び出し側の責任
    return fmt.Errorf("operation failed: %w", err)
}

4. インターフェースは消費者が定義する

提供者ではなく、消費者側でインターフェースを定義します。 これにより依存関係が逆転し、テストが容易になります。

// 消費者側のパッケージ
package handler

// 必要な操作だけを定義
type UserGetter interface {
    GetUser(id string) (*User, error)
}

func HandleGetUser(store UserGetter, id string) error {
    user, err := store.GetUser(id)
    // ...
}

---

設計原則の深掘り

SOLID原則のGo的解釈

1. Single Responsibility Principle（単一責任の原則）

各型は1つの責任のみを持つべきです。

// 悪い例：複数の責任
type UserManager struct {
    db       *sql.DB
    cache    *redis.Client
    logger   *log.Logger
    emailer  EmailService
}

func (um *UserManager) CreateUser(user *User) error {
    // DBへの保存
    // キャッシュの更新
    // ログの記録
    // メール送信
    // ...すべてをUserManagerが担当
}

// 良い例：責任を分割
type UserRepository struct {
    db *sql.DB
}

type UserCache struct {
    redis *redis.Client
}

type UserService struct {
    repo    *UserRepository
    cache   *UserCache
    logger  *log.Logger
    emailer EmailService
}

func (s *UserService) CreateUser(user *User) error {
    // 各コンポーネントに委譲
    if err := s.repo.Save(user); err != nil {
        return err
    }
    s.cache.Set(user.ID, user)
    s.logger.Info("User created", user.ID)
    s.emailer.SendWelcome(user.Email)
    return nil
}

2. Open/Closed Principle（開放/閉鎖の原則）

拡張に対して開いており、修正に対して閉じている。

// インターフェースで拡張可能に
type Validator interface {
    Validate(user *User) error
}

// 基本バリデーター
type EmailValidator struct{}

func (v *EmailValidator) Validate(user *User) error {
    if !strings.Contains(user.Email, "@") {
        return errors.New("invalid email")
    }
    return nil
}

// 新しいバリデーターを追加（既存コードを変更せず）
type AgeValidator struct {
    MinAge int
}

func (v *AgeValidator) Validate(user *User) error {
    if user.Age < v.MinAge {
        return fmt.Errorf("age must be at least %d", v.MinAge)
    }
    return nil
}

// 組み合わせて使用
type CompositeValidator struct {
    validators []Validator
}

func (c *CompositeValidator) Validate(user *User) error {
    for _, v := range c.validators {
        if err := v.Validate(user); err != nil {
            return err
        }
    }
    return nil
}

3. Liskov Substitution Principle（リスコフの置換原則）

派生型は基底型と置き換え可能であるべき（Goではインターフェースで実現）。

// io.Writerインターフェース
type Writer interface {
    Write(p []byte) (n int, err error)
}

// すべてのio.Writer実装は互換性がある
func SaveData(w io.Writer, data []byte) error {
    _, err := w.Write(data)
    return err
}

// どの実装でも動作する
func main() {
    var buf bytes.Buffer
    SaveData(&buf, []byte("data"))

    file, _ := os.Create("file.txt")
    defer file.Close()
    SaveData(file, []byte("data"))

    SaveData(os.Stdout, []byte("data"))
}

4. Interface Segregation Principle（インターフェース分離の原則）

クライアントは使用しないメソッドに依存すべきでない。

// 悪い例：巨大なインターフェース
type Datasource interface {
    GetUser(id string) (*User, error)
    SaveUser(user *User) error
    DeleteUser(id string) error
    ListUsers() ([]*User, error)
    GetProduct(id string) (*Product, error)
    SaveProduct(product *Product) error
    // ...さらに多くのメソッド
}

// 良い例：小さなインターフェース
type UserGetter interface {
    GetUser(id string) (*User, error)
}

type UserSaver interface {
    SaveUser(user *User) error
}

// 必要な機能だけを組み合わせる
type UserRepository interface {
    UserGetter
    UserSaver
}

5. Dependency Inversion Principle（依存性逆転の原則）

具象ではなく抽象に依存する。

// 悪い例：具象型に依存
type UserService struct {
    mysqlDB *mysql.DB  // 具体的な実装に依存
}

// 良い例：インターフェースに依存
type UserService struct {
    db UserRepository  // 抽象に依存
}

type UserRepository interface {
    GetUser(id string) (*User, error)
    SaveUser(user *User) error
}

// テスト時にモックを注入可能
type MockUserRepository struct {
    users map[string]*User
}

func (m *MockUserRepository) GetUser(id string) (*User, error) {
    user, ok := m.users[id]
    if !ok {
        return nil, errors.New("not found")
    }
    return user, nil
}

---

さらなる探求：高度なトピック

1. Generics（Go 1.18+）

イディオマティックGoにジェネリクスが加わりました。

// 型パラメータを使用したスタック
type Stack[T any] struct {
    items []T
}

func (s *Stack[T]) Push(item T) {
    s.items = append(s.items, item)
}

func (s *Stack[T]) Pop() (T, bool) {
    if len(s.items) == 0 {
        var zero T
        return zero, false
    }
    item := s.items[len(s.items)-1]
    s.items = s.items[:len(s.items)-1]
    return item, true
}

func main() {
    intStack := &Stack[int]{}
    intStack.Push(1)
    intStack.Push(2)

    stringStack := &Stack[string]{}
    stringStack.Push("hello")
    stringStack.Push("world")
}

ジェネリクスを使うべき時：

• コンテナ型（リスト、スタック、キュー）
• アルゴリズム関数（ソート、フィルタリング）
• ユーティリティ関数

ジェネリクスを避けるべき時：

• インターフェースで十分な場合
• 型が限定されている場合
• パフォーマンスが重要な場合（型アサーションより遅い可能性）

2. Runtime Internals：defer の仕組み

defer はどのように実装されているのでしょうか？

// 簡略化された疑似コード
func exampleFunction() {
    // defer文はdeferスタックに追加される
    deferStack := []func(){}

    deferStack = append(deferStack, func() {
        fmt.Println("Third")
    })

    deferStack = append(deferStack, func() {
        fmt.Println("Second")
    })

    deferStack = append(deferStack, func() {
        fmt.Println("First")
    })

    // 関数終了時、スタックをLIFO順で実行
    for i := len(deferStack) - 1; i >= 0; i-- {
        deferStack[i]()
    }
}

パフォーマンスへの影響：

• Go 1.13以前: 約50ns/defer（ヒープアロケーション）
• Go 1.14+: 約1ns/defer（スタックアロケーション）

3. Interface の内部表現

// インターフェース値の内部構造（簡略化）
type iface struct {
    tab  *itab          // 型情報とメソッドテーブル
    data unsafe.Pointer // 実際の値へのポインタ
}

type itab struct {
    inter *interfacetype  // インターフェースの型情報
    _type *_type          // 具象型の型情報
    hash  uint32          // _type.hashのコピー
    _     [4]byte
    fun   [1]uintptr     // メソッドテーブル（可変長）
}

この内部構造により：

• 型アサーションはO(1)（ハッシュ比較）
• メソッド呼び出しは1回の間接参照
• nil チェックは tab と data の両方をチェック

---

ビジュアル図解

オプションパターンの実行フロー

NewClient(opts...)
    ↓
1. デフォルト値で初期化
    client := &Client{
        timeout: 30s,
        baseURL: "http://localhost"
    }
    ↓
2. オプション関数を順次適用
    for _, opt := range opts {
        opt(client)  ← WithTimeout(60s)(client)
    }                ← WithBaseURL("https://api.example.com")(client)
    ↓
3. 設定済みクライアントを返す
    return client

defer の実行順序

func processFile() {
    file, _ := os.Open("data.txt")
    defer file.Close()           // ← 3番目に実行

    lock.Lock()
    defer lock.Unlock()          // ← 2番目に実行

    defer fmt.Println("Done")    // ← 1番目に実行

    // 処理...
}

実行順序（LIFO）:
    処理 → "Done" → lock.Unlock() → file.Close()

インターフェース分離の利点

従来の設計:
    [Controller] → [Service] → [HugeRepository]
                                    ↓
                        GetUser, SaveUser, DeleteUser
                        GetProduct, SaveProduct, DeleteProduct
                        GetOrder, SaveOrder, DeleteOrder
                        ...20+ methods

問題点:
- テストが困難（全メソッドをモック化）
- 変更の影響範囲が大きい
- 不要な依存関係

改善後:
    [UserController] → [UserService] → [UserGetter interface]
                                           ↓
                                   GetUser(id) (*User, error)

    [ProductController] → [ProductService] → [ProductGetter interface]
                                                 ↓
                                         GetProduct(id) (*Product, error)

利点:
- テストが容易（1つのメソッドだけモック）
- 疎結合
- 明確な責任分離

---

アンチパターンと回避方法

1. God Object（神オブジェクト）

// アンチパターン
type Application struct {
    db       *sql.DB
    cache    *redis.Client
    logger   *log.Logger
    config   *Config
    router   *Router
    auth     *AuthService
    email    *EmailService
    payment  *PaymentService
    // ...すべてをApplicationが保持
}

// 改善
type Application struct {
    config  *Config
    logger  *log.Logger
    server  *Server
    workers *WorkerPool
}

type Server struct {
    router  *Router
    handler *Handler
}

type Handler struct {
    userService    *UserService
    productService *ProductService
}

2. Premature Optimization（早すぎる最適化）

// アンチパターン: 最初から複雑な最適化
type Cache struct {
    shards    [256]*CacheShard  // シャーディング
    allocPool sync.Pool         // オブジェクトプール
    metrics   *MetricsCollector // メトリクス
    // ...複雑すぎる
}

// 改善: まずシンプルに
type Cache struct {
    mu    sync.RWMutex
    items map[string][]byte
}

// パフォーマンス問題が確認されてから最適化

3. Error Ignorance（エラー無視）

// アンチパターン
file, _ := os.Open("data.txt")  // エラーを無視
data, _ := io.ReadAll(file)     // エラーを無視

// 改善
file, err := os.Open("data.txt")
if err != nil {
    return fmt.Errorf("failed to open file: %w", err)
}
defer file.Close()

data, err := io.ReadAll(file)
if err != nil {
    return fmt.Errorf("failed to read file: %w", err)
}

---

明日の予習

Day 3: インターフェースの高度な使い方では、以下を学びます：

• 空インターフェースとany型の適切な使用法
• 型アサーションと型スイッチの高度なパターン
• インターフェースの内部実装とパフォーマンス
• 依存性注入パターンの実践
• モックを使った効果的なテスト戦略
• インターフェース駆動開発（IDD）

予習課題

以下のコードを読んで、インターフェースがどのように使われているか考えてみましょう：

package io

type Reader interface {
    Read(p []byte) (n int, err error)
}

type Writer interface {
    Write(p []byte) (n int, err error)
}

type ReadWriter interface {
    Reader
    Writer
}

質問:

• なぜ ReadWriter は Reader と Writer を埋め込んでいるのでしょうか？
• この設計の利点は何でしょうか？
• 実際のプロダクトでどのように活用できるでしょうか？

---

参考リソース

必読ドキュメント

• Effective Go - Go公式ガイド
• Go Code Review Comments - コードレビューのベストプラクティス
• Go Proverbs - Goの格言集
• Uber Go Style Guide - Uberのスタイルガイド

推奨書籍

• "The Go Programming Language" by Alan Donovan & Brian Kernighan
• "100 Go Mistakes and How to Avoid Them" by Teiva Harsanyi
• "Learning Go" by Jon Bodner

オープンソースプロジェクト

• Kubernetes (https://github.com/kubernetes/kubernetes)

• Docker (https://github.com/moby/moby)

• Prometheus (https://github.com/prometheus/prometheus)

• Hugo (https://github.com/gohugoio/hugo)

---

イディオマティックGoを書くことで、あなたのコードはGoコミュニティに受け入れられ、メンテナンスしやすくなります！

Remember: "Clear is better than clever" - Goの哲学