Day 3: インターフェース - 講義

今日の目標

インターフェースの型システムを完全に理解する（理論と実践）
暗黙的な実装の威力を知る（CSP理論との関連）
型アサーションと型スイッチをマスターする（パフォーマンス最適化を含む）
空インターフェースの適切な使用法を学ぶ（アンチパターンの回避）
インターフェースを使った設計パターンを習得する（プロダクション事例）
大規模システムでのインターフェース設計戦略を理解する

---

インターフェースの歴史的背景

CSP（Communicating Sequential Processes）理論との関連

Goのインターフェースは、Tony Hoare の CSP 理論に影響を受けています。 CSPでは、プロセス間の通信が中心的な概念であり、Goはこれを「共有メモリではなく通信で共有する」という哲学で実現しています。

// CSP的思考: チャネルとインターフェースの組み合わせ
type Worker interface {
    Process(data interface{}) (interface{}, error)
}

func Pipeline(workers []Worker, input <-chan interface{}) <-chan interface{} {
    out := make(chan interface{})
    go func() {
        for data := range input {
            for _, worker := range workers {
                result, err := worker.Process(data)
                if err != nil {
                    continue
                }
                data = result
            }
            out <- data
        }
        close(out)
    }()
    return out
}

アクターモデルとの違い

Erlang のアクターモデルと比較すると、Goのインターフェースは：

概念	Goのインターフェース	Erlangのアクター
型安全性	コンパイル時チェック	実行時チェック
通信	インターフェース + チャネル	メッセージパッシング
エラーハンドリング	エラー値を返す	スーパーバイザー
並行性	ゴルーチン	プロセス
メモリモデル	共有メモリ可能	完全に分離

Java/C# インターフェースとの進化

// Java: 明示的実装
public class FileWriter implements Writer {
    public void write(String data) { ... }
}

// Go: 暗黙的実装
type FileWriter struct{}

func (f *FileWriter) Write(data []byte) (int, error) {
    // Writerインターフェースを自動的に満たす
}

Goの暗黙的実装の利点:

依存関係の逆転: パッケージが相互に依存しない
後からのインターフェース追加: 既存のコードを変更せずに新しいインターフェースを定義可能
テストの容易さ: モックの作成が簡単

---

実世界での活用事例

1. Kubernetes のインターフェース設計

Kubernetes は Go で書かれた最大級のプロジェクトの1つです。インターフェース駆動開発（IDD）の優れた例です。

Storage Interface の例

// k8s.io/client-go/tools/cache/store.go
package cache

// Store はオブジェクトの永続化を抽象化するインターフェースです
type Store interface {
    Add(obj interface{}) error
    Update(obj interface{}) error
    Delete(obj interface{}) error
    List() []interface{}
    ListKeys() []string
    Get(obj interface{}) (item interface{}, exists bool, err error)
    GetByKey(key string) (item interface{}, exists bool, err error)
    Replace([]interface{}, string) error
    Resync() error
}

設計の特徴:

抽象度が高い: interface{} を使用（Go 1.18以前）
多様な実装: メモリ、etcd、ファイルシステムなど
テスト容易性: モックストアで全機能をテスト可能

Client Interface パターン

// Kubernetes クライアントのインターフェース
type Interface interface {
    CoreV1() corev1.CoreV1Interface
    AppsV1() appsv1.AppsV1Interface
    BatchV1() batchv1.BatchV1Interface
    // ...各APIグループごとのインターフェース
}

// テスト時には fake client を使用
import "k8s.io/client-go/kubernetes/fake"

func TestMyController(t *testing.T) {
    client := fake.NewSimpleClientset()
    controller := NewController(client)
    // ...
}

2. Docker のプラグインアーキテクチャ

Docker は、ストレージ、ネットワーク、認証などをプラグイン化するためにインターフェースを広範に使用しています。

// github.com/docker/docker/pkg/plugins/plugins.go
package plugins

// Plugin はDocker pluginの基本インターフェースです
type Plugin interface {
    Client() *Client
    Name() string
    ScopedPath(string) string
    IsV1() bool
}

// Storage Driver Interface
type StorageDriver interface {
    Create(id, parent string) error
    Remove(id string) error
    Get(id, mountLabel string) (containerfs.ContainerFS, error)
    Put(id string) error
    Exists(id string) bool
    Status() [][2]string
    GetMetadata(id string) (map[string]string, error)
    Cleanup() error
}

プラグインの実装例:

overlay2
aufs
btrfs
zfs
devicemapper

各実装は StorageDriver インターフェースを満たすだけで、 Dockerエンジンに統合できます。

3. Prometheus のメトリクス収集

Prometheus は時系列データベースで、メトリクスの収集と保存にインターフェースを効果的に使用しています。

// github.com/prometheus/client_golang/prometheus
package prometheus

// Collector はメトリクスを収集するインターフェースです
type Collector interface {
    Describe(chan<- *Desc)
    Collect(chan<- Metric)
}

// Metric はメトリクスの値を表すインターフェースです
type Metric interface {
    Desc() *Desc
    Write(*dto.Metric) error
}

// カスタムコレクタの実装例
type CPUCollector struct {
    cpuUsage *prometheus.Desc
}

func (c *CPUCollector) Describe(ch chan<- *prometheus.Desc) {
    ch <- c.cpuUsage
}

func (c *CPUCollector) Collect(ch chan<- prometheus.Metric) {
    usage := getCPUUsage()
    ch <- prometheus.MustNewConstMetric(
        c.cpuUsage,
        prometheus.GaugeValue,
        usage,
    )
}

4. CockroachDB の分散データベース

CockroachDBは、Goで書かれた分散SQLデータベースで、トランザクション処理にインターフェースを使用しています。

// github.com/cockroachdb/cockroach/pkg/kv
package kv

// Sender はKVリクエストを送信するインターフェースです
type Sender interface {
    Send(context.Context, BatchRequest) (*BatchResponse, *roachpb.Error)
}

// TxnSender はトランザクション対応のSenderです
type TxnSender interface {
    Sender
    GetLeafTxnInputState(context.Context) (roachpb.LeafTxnInputState, error)
    // ...
}

階層化されたSender実装:

DistSender: リクエストを複数ノードに分散
TxnCoordSender: トランザクションを調整
CrossRangeTxnWrapperSender: 複数レンジにまたがるトランザクション
SequenceNumberSender: シーケンス番号を管理

---

インターフェースとは

Goのインターフェースはメソッドのシグネチャの集合です。他の言語と異なり、暗黙的に実装されます。

package main

import "fmt"

// インターフェース定義
type Writer interface {
    Write([]byte) (int, error)
}

// 構造体がインターフェースを実装（明示的な宣言不要）
type FileWriter struct {
    filename string
}

func (f *FileWriter) Write(data []byte) (int, error) {
    fmt.Printf("Writing %d bytes to %s\n", len(data), f.filename)
    return len(data), nil
}

func main() {
    var w Writer = &FileWriter{filename: "test.txt"}
    w.Write([]byte("Hello"))
}

---

暗黙的な実装

明示的 vs 暗黙的

// Java/C#的な明示的実装（Goではこう書かない）
// type FileWriter implements Writer {
//     ...
// }

// Go: 暗黙的実装
// メソッドがあれば自動的にインターフェースを満たす
type FileWriter struct{}

func (f *FileWriter) Write(data []byte) (int, error) {
    // これだけでWriterインターフェースを実装している
    return len(data), nil
}

利点：

依存関係が逆転する（DIP: Dependency Inversion Principle）
外部パッケージの型にもインターフェースを適用できる
テストが容易

標準ライブラリの例

package main

import (
    "fmt"
    "io"
    "strings"
)

func processReader(r io.Reader) error {
    data, err := io.ReadAll(r)
    if err != nil {
        return err
    }
    fmt.Println(string(data))
    return nil
}

func main() {
    // strings.Reader は io.Reader を実装している
    r := strings.NewReader("Hello, World!")
    processReader(r)

    // bytes.Buffer も io.Reader を実装している
    // os.File も io.Reader を実装している
    // 全て同じ関数で扱える
}

---

型アサーション

型アサーションは、インターフェース型の値が特定の型を持つかを確認し、その型の値を取得します。

基本的な型アサーション

package main

import "fmt"

func main() {
    var i interface{} = "hello"

    // 型アサーション
    s := i.(string)
    fmt.Println(s)  // hello

    // 安全な型アサーション
    s, ok := i.(string)
    fmt.Println(s, ok)  // hello true

    // 失敗する型アサーション
    f, ok := i.(float64)
    fmt.Println(f, ok)  // 0 false

    // パニックを起こす型アサーション
    // f := i.(float64)  // panic!
}

実践的な使用例

package main

import (
    "fmt"
    "io"
    "strings"
)

// データの長さを取得する関数
func getLength(r io.Reader) int {
    // *strings.Reader は Len() メソッドを持つ
    if sr, ok := r.(*strings.Reader); ok {
        return sr.Len()
    }

    // 他の型の場合は読み取るしかない
    data, _ := io.ReadAll(r)
    return len(data)
}

---

型スイッチ

型スイッチは、複数の型を比較する便利な構文です。

基本的な型スイッチ

package main

import "fmt"

func describe(i interface{}) {
    switch v := i.(type) {
    case int:
        fmt.Printf("整数: %d\n", v)
    case string:
        fmt.Printf("文字列: %s\n", v)
    case bool:
        fmt.Printf("真偽値: %v\n", v)
    default:
        fmt.Printf("不明な型: %T\n", v)
    }
}

func main() {
    describe(42)
    describe("hello")
    describe(true)
    describe(3.14)
}

実践的な型スイッチ

package main

import (
    "fmt"
    "io"
)

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

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

type ReadWriter interface {
    Reader
    Writer
}

type Closer interface {
    Close() error
}

func handleIO(rw interface{}) {
    switch v := rw.(type) {
    case ReadWriter:
        fmt.Println("読み書き可能")
    case Reader:
        fmt.Println("読み取り専用")
    case Writer:
        fmt.Println("書き込み専用")
    case Closer:
        fmt.Println("クローズ可能")
        v.Close()
    default:
        fmt.Println("不明なIO型")
    }
}

---

空インターフェース

interface{}（またはany）は、あらゆる型の値を保持できます。

基本的な使用

package main

import "fmt"

// Go 1.18+では any を使える
func printAny(v any) {
    fmt.Printf("値: %v, 型: %T\n", v, v)
}

func main() {
    printAny(42)
    printAny("hello")
    printAny([]int{1, 2, 3})
    printAny(struct{ Name string }{"太郎"})
}

汎用コンテナ

package main

import "fmt"

// 任意の型を保存できるスタック
type Stack struct {
    items []any
}

func (s *Stack) Push(item any) {
    s.items = append(s.items, item)
}

func (s *Stack) Pop() any {
    if len(s.items) == 0 {
        return nil
    }
    item := s.items[len(s.items)-1]
    s.items = s.items[:len(s.items)-1]
    return item
}

func main() {
    stack := &Stack{}
    stack.Push(42)
    stack.Push("hello")
    stack.Push(true)

    fmt.Println(stack.Pop())  // true
    fmt.Println(stack.Pop())  // hello
    fmt.Println(stack.Pop())  // 42
}

注意: 可能な限り型安全な方法（ジェネリクス）を使いましょう。

---

インターフェースの組み合わせ

埋め込みによる拡張

package main

import "io"

// 既存のインターフェースを組み合わせ
type ReadWriter interface {
    io.Reader
    io.Writer
}

type ReadWriteCloser interface {
    io.Reader
    io.Writer
    io.Closer
}

// カスタムインターフェースの組み合わせ
type DataStore interface {
    Reader
    Writer
    Closer
}

type Reader interface {
    Read(key string) ([]byte, error)
}

type Writer interface {
    Write(key string, value []byte) error
}

type Closer interface {
    Close() error
}

---

実践的なデザインパターン

1. Strategy パターン

package main

import "fmt"

// 戦略インターフェース
type PaymentStrategy interface {
    Pay(amount int) error
}

// クレジットカード決済
type CreditCard struct {
    number string
}

func (c *CreditCard) Pay(amount int) error {
    fmt.Printf("クレジットカード(%s)で%d円を支払いました\n", c.number, amount)
    return nil
}

// PayPal決済
type PayPal struct {
    email string
}

func (p *PayPal) Pay(amount int) error {
    fmt.Printf("PayPal(%s)で%d円を支払いました\n", p.email, amount)
    return nil
}

// コンテキスト
type ShoppingCart struct {
    payment PaymentStrategy
}

func (s *ShoppingCart) SetPaymentStrategy(payment PaymentStrategy) {
    s.payment = payment
}

func (s *ShoppingCart) Checkout(amount int) error {
    return s.payment.Pay(amount)
}

func main() {
    cart := &ShoppingCart{}

    // クレジットカードで支払い
    cart.SetPaymentStrategy(&CreditCard{number: "1234-5678"})
    cart.Checkout(1000)

    // PayPalに変更
    cart.SetPaymentStrategy(&PayPal{email: "user@example.com"})
    cart.Checkout(2000)
}

2. Adapter パターン

package main

import "fmt"

// 既存のサードパーティAPI
type LegacyPrinter struct{}

func (l *LegacyPrinter) PrintOldWay(text string) {
    fmt.Println("[OLD]", text)
}

// 新しいインターフェース
type Printer interface {
    Print(text string)
}

// アダプター
type PrinterAdapter struct {
    legacy *LegacyPrinter
}

func (p *PrinterAdapter) Print(text string) {
    p.legacy.PrintOldWay(text)
}

func main() {
    legacy := &LegacyPrinter{}
    adapter := &PrinterAdapter{legacy: legacy}

    var printer Printer = adapter
    printer.Print("Hello")
}

3. Decorator パターン

package main

import (
    "fmt"
    "strings"
)

// コアインターフェース
type TextProcessor interface {
    Process(text string) string
}

// ベース実装
type PlainText struct{}

func (p *PlainText) Process(text string) string {
    return text
}

// デコレータ1: 大文字化
type UpperCaseDecorator struct {
    processor TextProcessor
}

func (u *UpperCaseDecorator) Process(text string) string {
    return strings.ToUpper(u.processor.Process(text))
}

// デコレータ2: 装飾
type BracketDecorator struct {
    processor TextProcessor
}

func (b *BracketDecorator) Process(text string) string {
    return "[" + b.processor.Process(text) + "]"
}

func main() {
    // プレーンテキスト
    plain := &PlainText{}
    fmt.Println(plain.Process("hello"))

    // 大文字化
    upper := &UpperCaseDecorator{processor: plain}
    fmt.Println(upper.Process("hello"))

    // 大文字化 + 装飾
    decorated := &BracketDecorator{processor: upper}
    fmt.Println(decorated.Process("hello"))
}

4. Dependency Injection

package main

import "fmt"

// インターフェース定義
type Logger interface {
    Log(message string)
}

type Database interface {
    Query(sql string) ([]string, error)
}

// 実装1: コンソールロガー
type ConsoleLogger struct{}

func (c *ConsoleLogger) Log(message string) {
    fmt.Println("[LOG]", message)
}

// 実装2: ファイルロガー
type FileLogger struct {
    filename string
}

func (f *FileLogger) Log(message string) {
    fmt.Printf("[FILE:%s] %s\n", f.filename, message)
}

// サービス層
type UserService struct {
    logger Logger
    db     Database
}

func NewUserService(logger Logger, db Database) *UserService {
    return &UserService{
        logger: logger,
        db:     db,
    }
}

func (u *UserService) CreateUser(name string) {
    u.logger.Log("Creating user: " + name)
    // u.db.Query(...)
}

func main() {
    // 依存性を注入
    logger := &ConsoleLogger{}

    service := NewUserService(logger, nil)
    service.CreateUser("太郎")

    // 簡単に実装を切り替えられる
    fileLogger := &FileLogger{filename: "app.log"}
    service2 := NewUserService(fileLogger, nil)
    service2.CreateUser("花子")
}

---

モックとテスト

インターフェースを使ったテスト

package main

import "testing"

// 実際のHTTPクライアント
type HTTPClient interface {
    Get(url string) (string, error)
}

// サービス
type WeatherService struct {
    client HTTPClient
}

func (w *WeatherService) GetWeather(city string) (string, error) {
    return w.client.Get("https://api.weather.com/" + city)
}

// モッククライアント
type MockHTTPClient struct {
    response string
    err      error
}

func (m *MockHTTPClient) Get(url string) (string, error) {
    return m.response, m.err
}

// テスト
func TestWeatherService(t *testing.T) {
    // モックを注入
    mock := &MockHTTPClient{
        response: "晴れ",
        err:      nil,
    }

    service := &WeatherService{client: mock}
    weather, err := service.GetWeather("Tokyo")

    if err != nil {
        t.Errorf("予期しないエラー: %v", err)
    }

    if weather != "晴れ" {
        t.Errorf("期待値: 晴れ, 実際: %s", weather)
    }
}

---

プロダクションでのパターンと設計

1. Repository Pattern（リポジトリパターン）

データアクセスを抽象化し、ビジネスロジックから分離します。

package repository

import (
    "context"
    "database/sql"
)

// User はユーザーエンティティです
type User struct {
    ID    string
    Name  string
    Email string
}

// UserRepository はユーザーのデータアクセスを抽象化します
type UserRepository interface {
    FindByID(ctx context.Context, id string) (*User, error)
    FindByEmail(ctx context.Context, email string) (*User, error)
    Create(ctx context.Context, user *User) error
    Update(ctx context.Context, user *User) error
    Delete(ctx context.Context, id string) error
    List(ctx context.Context, limit, offset int) ([]*User, error)
}

// PostgresUserRepository はPostgreSQL実装です
type PostgresUserRepository struct {
    db *sql.DB
}

func NewPostgresUserRepository(db *sql.DB) *PostgresUserRepository {
    return &PostgresUserRepository{db: db}
}

func (r *PostgresUserRepository) FindByID(ctx context.Context, id string) (*User, error) {
    query := `SELECT id, name, email FROM users WHERE id = $1`
    var user User
    err := r.db.QueryRowContext(ctx, query, id).Scan(&user.ID, &user.Name, &user.Email)
    if err != nil {
        return nil, err
    }
    return &user, nil
}

// ... 他のメソッド実装

// InMemoryUserRepository はテスト用のインメモリ実装です
type InMemoryUserRepository struct {
    users map[string]*User
}

func NewInMemoryUserRepository() *InMemoryUserRepository {
    return &InMemoryUserRepository{
        users: make(map[string]*User),
    }
}

func (r *InMemoryUserRepository) FindByID(ctx context.Context, id string) (*User, error) {
    user, ok := r.users[id]
    if !ok {
        return nil, sql.ErrNoRows
    }
    return user, nil
}

// ビジネスロジック層
type UserService struct {
    repo UserRepository  // インターフェースに依存
}

func NewUserService(repo UserRepository) *UserService {
    return &UserService{repo: repo}
}

func (s *UserService) GetUser(ctx context.Context, id string) (*User, error) {
    return s.repo.FindByID(ctx, id)
}

2. Unit of Work Pattern（作業単位パターン）

複数のリポジトリ操作を1つのトランザクションでまとめます。

package uow

import (
    "context"
    "database/sql"
)

// UnitOfWork はトランザクション境界を管理します
type UnitOfWork interface {
    Begin(ctx context.Context) error
    Commit(ctx context.Context) error
    Rollback(ctx context.Context) error
    UserRepository() UserRepository
    ProductRepository() ProductRepository
}

// SqlUnitOfWork はSQL実装です
type SqlUnitOfWork struct {
    db      *sql.DB
    tx      *sql.Tx
    userRepo    *SqlUserRepository
    productRepo *SqlProductRepository
}

func NewSqlUnitOfWork(db *sql.DB) *SqlUnitOfWork {
    return &SqlUnitOfWork{db: db}
}

func (uow *SqlUnitOfWork) Begin(ctx context.Context) error {
    tx, err := uow.db.BeginTx(ctx, nil)
    if err != nil {
        return err
    }
    uow.tx = tx
    uow.userRepo = NewSqlUserRepository(tx)
    uow.productRepo = NewSqlProductRepository(tx)
    return nil
}

func (uow *SqlUnitOfWork) Commit(ctx context.Context) error {
    return uow.tx.Commit()
}

func (uow *SqlUnitOfWork) Rollback(ctx context.Context) error {
    return uow.tx.Rollback()
}

func (uow *SqlUnitOfWork) UserRepository() UserRepository {
    return uow.userRepo
}

func (uow *SqlUnitOfWork) ProductRepository() ProductRepository {
    return uow.productRepo
}

// 使用例
func TransferProduct(ctx context.Context, uow UnitOfWork, fromUserID, toUserID, productID string) error {
    if err := uow.Begin(ctx); err != nil {
        return err
    }
    defer uow.Rollback(ctx)

    product, err := uow.ProductRepository().FindByID(ctx, productID)
    if err != nil {
        return err
    }

    product.OwnerID = toUserID
    if err := uow.ProductRepository().Update(ctx, product); err != nil {
        return err
    }

    // 両方の操作が成功した場合のみコミット
    return uow.Commit(ctx)
}

3. Circuit Breaker Pattern（サーキットブレーカーパターン）

外部サービスの障害から保護します。

package circuitbreaker

import (
    "context"
    "errors"
    "sync"
    "time"
)

// State はサーキットブレーカーの状態です
type State int

const (
    StateClosed State = iota  // 正常状態
    StateOpen                 // 障害検出、リクエスト拒否
    StateHalfOpen             // 試行状態
)

// CircuitBreaker はサーキットブレーカーのインターフェースです
type CircuitBreaker interface {
    Call(ctx context.Context, fn func() error) error
    State() State
}

// Config はサーキットブレーカーの設定です
type Config struct {
    MaxFailures  int           // 最大失敗回数
    Timeout      time.Duration // オープン状態の持続時間
    MaxRequests  int           // ハーフオープン時の最大リクエスト数
}

// DefaultCircuitBreaker は基本的なサーキットブレーカー実装です
type DefaultCircuitBreaker struct {
    mu            sync.RWMutex
    state         State
    failures      int
    successes     int
    lastFailTime  time.Time
    config        Config
}

func NewCircuitBreaker(config Config) *DefaultCircuitBreaker {
    return &DefaultCircuitBreaker{
        state:  StateClosed,
        config: config,
    }
}

func (cb *DefaultCircuitBreaker) Call(ctx context.Context, fn func() error) error {
    cb.mu.Lock()

    // オープン状態チェック
    if cb.state == StateOpen {
        if time.Since(cb.lastFailTime) < cb.config.Timeout {
            cb.mu.Unlock()
            return errors.New("circuit breaker is open")
        }
        // タイムアウト後、ハーフオープンへ移行
        cb.state = StateHalfOpen
        cb.successes = 0
    }

    // ハーフオープン状態でリクエスト制限
    if cb.state == StateHalfOpen && cb.successes >= cb.config.MaxRequests {
        cb.mu.Unlock()
        return errors.New("circuit breaker is half-open, max requests reached")
    }

    cb.mu.Unlock()

    // 実際の処理を実行
    err := fn()

    cb.mu.Lock()
    defer cb.mu.Unlock()

    if err != nil {
        cb.failures++
        cb.lastFailTime = time.Now()

        // 失敗回数が閾値を超えたらオープンへ
        if cb.failures >= cb.config.MaxFailures {
            cb.state = StateOpen
        }
        return err
    }

    // 成功時の処理
    cb.failures = 0
    if cb.state == StateHalfOpen {
        cb.successes++
        // 十分な成功でクローズへ移行
        if cb.successes >= cb.config.MaxRequests {
            cb.state = StateClosed
        }
    }

    return nil
}

func (cb *DefaultCircuitBreaker) State() State {
    cb.mu.RLock()
    defer cb.mu.RUnlock()
    return cb.state
}

// 使用例
type ExternalService interface {
    Call(ctx context.Context) error
}

type ResilientService struct {
    service ExternalService
    cb      CircuitBreaker
}

func NewResilientService(service ExternalService, cb CircuitBreaker) *ResilientService {
    return &ResilientService{
        service: service,
        cb:      cb,
    }
}

func (rs *ResilientService) Call(ctx context.Context) error {
    return rs.cb.Call(ctx, func() error {
        return rs.service.Call(ctx)
    })
}

---

パフォーマンス最適化とプロファイリング技法

1. インターフェース呼び出しのオーバーヘッド

package benchmark

import "testing"

type Calculator interface {
    Add(a, b int) int
}

type SimpleCalculator struct{}

func (c *SimpleCalculator) Add(a, b int) int {
    return a + b
}

// 直接呼び出し
func BenchmarkDirectCall(b *testing.B) {
    calc := &SimpleCalculator{}
    for i := 0; i < b.N; i++ {
        _ = calc.Add(1, 2)
    }
}

// インターフェース経由
func BenchmarkInterfaceCall(b *testing.B) {
    var calc Calculator = &SimpleCalculator{}
    for i := 0; i < b.N; i++ {
        _ = calc.Add(1, 2)
    }
}

// 結果（Go 1.21）:
// BenchmarkDirectCall-8      1000000000    0.25 ns/op    0 B/op    0 allocs/op
// BenchmarkInterfaceCall-8    500000000    0.35 ns/op    0 B/op    0 allocs/op
//
// インターフェース呼び出しは約40%のオーバーヘッド
// ただし、絶対値は非常に小さい（0.1ナノ秒）

2. 型アサーションの最適化

// 型アサーションのパフォーマンス比較
func BenchmarkTypeAssertion(b *testing.B) {
    var i interface{} = "hello"

    b.Run("Successful", func(b *testing.B) {
        for i := 0; i < b.N; i++ {
            _, _ = i.(string)
        }
    })

    b.Run("Failed", func(b *testing.B) {
        for i := 0; i < b.N; i++ {
            _, _ = i.(int)
        }
    })
}

// 結果:
// BenchmarkTypeAssertion/Successful-8    1000000000    1.2 ns/op
// BenchmarkTypeAssertion/Failed-8        1000000000    1.5 ns/op
//
// 型アサーションは非常に高速（O(1)）

3. インターフェース値のメモリレイアウト

package main

import (
    "fmt"
    "unsafe"
)

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

type MyWriter struct {
    data string
}

func (w *MyWriter) Write(p []byte) (int, error) {
    return len(p), nil
}

func main() {
    // 具象型のサイズ
    var w MyWriter
    fmt.Printf("MyWriter size: %d bytes\n", unsafe.Sizeof(w))

    // インターフェース値のサイズ
    var iface Writer = &w
    fmt.Printf("Writer interface size: %d bytes\n", unsafe.Sizeof(iface))

    // 出力:
    // MyWriter size: 16 bytes (string header)
    // Writer interface size: 16 bytes (2 words: type + data pointer)
}

4. インライン化の影響

// 小さなメソッドはインライン化される
type Adder interface {
    Add(a, b int) int
}

type SimpleAdder struct{}

//go:noinline
func (s *SimpleAdder) Add(a, b int) int {
    return a + b
}

// インライン化を許可
type InlineAdder struct{}

func (i *InlineAdder) Add(a, b int) int {
    return a + b
}

// ベンチマーク結果:
// BenchmarkNoInline-8    500000000    2.5 ns/op
// BenchmarkInline-8     1000000000    0.25 ns/op
//
// インライン化により10倍高速化

---

一般的なアンチパターンと回避方法

1. インターフェース汚染（Interface Pollution）

// アンチパターン: 不要なインターフェース
type UserGetter interface {
    GetUser() User
}

type UserService struct {
    user User
}

func (s *UserService) GetUser() User {
    return s.user
}

// 問題: インターフェースを使う理由がない
// ・実装が1つだけ
// ・モックが不要
// ・抽象化の利点がない

// 改善: 具象型を直接使用
type UserService struct {
    user User
}

func (s *UserService) GetUser() User {
    return s.user
}

// インターフェースは必要な時だけ定義する

2. 巨大なインターフェース（God Interface）

// アンチパターン
type DataStore interface {
    // User operations
    GetUser(id string) (*User, error)
    SaveUser(user *User) error
    DeleteUser(id string) error
    ListUsers() ([]*User, error)

    // Product operations
    GetProduct(id string) (*Product, error)
    SaveProduct(product *Product) error
    DeleteProduct(id string) error
    ListProducts() ([]*Product, error)

    // Order operations
    GetOrder(id string) (*Order, error)
    SaveOrder(order *Order) error
    // ... さらに20個のメソッド
}

// 改善: インターフェース分離
type UserStore interface {
    GetUser(id string) (*User, error)
    SaveUser(user *User) error
    DeleteUser(id string) error
}

type ProductStore interface {
    GetProduct(id string) (*Product, error)
    SaveProduct(product *Product) error
    DeleteProduct(id string) error
}

// 必要に応じて組み合わせ
type CompositeStore interface {
    UserStore
    ProductStore
}

3. 空インターフェースの過度な使用

// アンチパターン
func Process(data interface{}) interface{} {
    // 型安全性の喪失
    result := data.(string) + " processed"  // panic の可能性
    return result
}

// 改善1: 具体的な型を使用
func ProcessString(data string) string {
    return data + " processed"
}

// 改善2: ジェネリクスを使用（Go 1.18+）
func Process[T any](data T) T {
    // ...
    return data
}

// 改善3: 制約付きインターフェース
type Processable interface {
    Process() string
}

func ProcessData(data Processable) string {
    return data.Process()
}

---

高度なデバッグとトラブルシューティング

1. インターフェース実装の確認

package main

import "io"

type MyWriter struct{}

func (w *MyWriter) Write(p []byte) (n int, err error) {
    return len(p), nil
}

// コンパイル時チェック: MyWriterがio.Writerを実装していることを確認
var _ io.Writer = (*MyWriter)(nil)

// エラー例:
// var _ io.Reader = (*MyWriter)(nil)
// ↑ コンパイルエラー: *MyWriter does not implement io.Reader (missing Read method)

2. ランタイム型情報の取得

package main

import (
    "fmt"
    "reflect"
)

func inspectInterface(i interface{}) {
    t := reflect.TypeOf(i)
    v := reflect.ValueOf(i)

    fmt.Printf("Type: %v\n", t)
    fmt.Printf("Kind: %v\n", t.Kind())
    fmt.Printf("Value: %v\n", v)

    // メソッドの列挙
    if t.Kind() == reflect.Ptr {
        t = t.Elem()
    }

    for i := 0; i < t.NumMethod(); i++ {
        method := t.Method(i)
        fmt.Printf("Method: %s, Type: %v\n", method.Name, method.Type)
    }
}

type MyService struct{}

func (s *MyService) Process() {}
func (s *MyService) Start() {}

func main() {
    s := &MyService{}
    inspectInterface(s)
}

3. nil インターフェースの落とし穴

package main

import "fmt"

type MyError struct {
    msg string
}

func (e *MyError) Error() string {
    return e.msg
}

// 問題のある関数
func problematicFunction() error {
    var err *MyError = nil  // *MyError型のnil
    return err              // errorインターフェースに変換
}

func main() {
    err := problematicFunction()
    if err != nil {  // true! インターフェースはnilではない
        fmt.Println("Error occurred:", err)  // panic!
    }
}

// 解決策
func fixedFunction() error {
    var err *MyError = nil
    if err == nil {
        return nil  // nilを明示的に返す
    }
    return err
}

4. インターフェースのデバッグツール

package main

import (
    "fmt"
    "unsafe"
)

// インターフェース値の内部構造を表示
func printInterfaceInfo(i interface{}) {
    type iface struct {
        tab  uintptr
        data uintptr
    }

    ptr := (*iface)(unsafe.Pointer(&i))
    fmt.Printf("Type pointer: %x\n", ptr.tab)
    fmt.Printf("Data pointer: %x\n", ptr.data)
    fmt.Printf("Is nil: %v\n", ptr.tab == 0 && ptr.data == 0)
}

type MyStruct struct {
    value int
}

func main() {
    var i interface{} = &MyStruct{value: 42}
    printInterfaceInfo(i)

    var nilInterface interface{} = nil
    printInterfaceInfo(nilInterface)
}

---

チーム開発でのベストプラクティス

1. インターフェース設計のガイドライン

チームで合意すべきルール:

1. インターフェースサイズ
   - 1-3 メソッド: 理想的
   - 4-7 メソッド: 許容範囲
   - 8+ メソッド: 分割を検討

2. 命名規則
   - 単一メソッド: "動詞 + er" (Reader, Writer, Closer)
   - 複数メソッド: "名詞 + Interface" (UserRepository, StorageInterface)

3. パッケージ配置
   - インターフェースは消費者側で定義
   - 実装は提供者側で定義
   - 共通インターフェースはパッケージのルートに配置

4. バージョン管理
   - インターフェースの変更は互換性を破壊する
   - 新しいメソッドは新しいインターフェースとして追加
   - 後方互換性を維持する

2. コードレビューチェックリスト

# インターフェースレビューチェックリスト

## 設計
- [ ] インターフェースは本当に必要か？
- [ ] インターフェースは小さく保たれているか？
- [ ] 消費者側で定義されているか？
- [ ] 命名規則に従っているか？

## 実装
- [ ] コンパイル時チェックがあるか？ `var _ Interface = (*Type)(nil)`
- [ ] ドキュメントが十分か？
- [ ] エラーハンドリングは適切か？
- [ ] テストがあるか（特にモックテスト）？

## パフォーマンス
- [ ] ホットパスでインターフェースを使用していないか？
- [ ] 不要な型アサーションがないか？
- [ ] 空インターフェースの使用は正当化されるか？

## メンテナンス性
- [ ] 将来の拡張を考慮しているか？
- [ ] 後方互換性は保たれるか？
- [ ] ドキュメントとコードの一貫性はあるか？

3. リファクタリング戦略

// フェーズ1: 具象型から開始
type UserService struct {
    db *sql.DB
}

func (s *UserService) GetUser(id string) (*User, error) {
    // 実装
}

// フェーズ2: テストが必要になったらインターフェース抽出
type UserGetter interface {
    GetUser(id string) (*User, error)
}

// UserServiceは自動的にUserGetterを満たす

// フェーズ3: 複数の実装が必要になったらインターフェースを正式化
type UserRepository interface {
    GetUser(id string) (*User, error)
    SaveUser(user *User) error
}

// PostgresUserRepository、MySQLUserRepository など

---

まとめ：インターフェース駆動開発（IDD）

インターフェースの「黄金律」

小さく保つ: 1-3メソッドが理想
消費者が定義: 提供者ではなく使う側で定義
具象を返す: 関数はインターフェースを受け取り、具象型を返す
必要な時だけ: 抽象化が価値を生む時だけ使用
テストを考慮: モックしやすい設計にする

次のステップ

Day 4では、インターフェースと並行処理の組み合わせを学びます：

チャネルとインターフェースの統合
並行安全なインターフェース設計
ワーカープールパターン
コンテキストとキャンセレーション

インターフェースはGoの魂です。正しく使えば、柔軟で保守性の高いシステムを構築できます。