Go言語のインターフェース：暗黙の実装、any、nilの罠

インターフェースはメソッドの集合

インターフェース型はメソッドのシグネチャを列挙します。それらのメソッドを持つ型はどれでも、そう宣言することなくインターフェースを満たします。

package main

import (
	"fmt"
	"math"
)

type Shape interface {
	Area() float64
	Perimeter() float64
}

type Rect struct{ W, H float64 }

func (r Rect) Area() float64      { return r.W * r.H }
func (r Rect) Perimeter() float64 { return 2 * (r.W + r.H) }

type Circle struct{ R float64 }

func (c Circle) Area() float64      { return math.Pi * c.R * c.R }
func (c Circle) Perimeter() float64 { return 2 * math.Pi * c.R }

func describe(s Shape) {
	fmt.Printf("%T area=%.2f perimeter=%.2f\n", s, s.Area(), s.Perimeter())
}

func main() {
	shapes := []Shape{Rect{3, 4}, Circle{1}}
	for _, s := range shapes {
		describe(s)
	}
}

Rect も Circle も Shape に触れていません。これが暗黙の実装で、Goのインターフェースを特徴づける性質です。他のパッケージの型がすでに満たしているインターフェースを、そのコードに触れることなく自分のパッケージで定義できます。

標準ライブラリの小さなインターフェース

Goのコードは、メソッドが1つか2つのインターフェースを好みます。最も重要なものは次のとおりです。

io.Reader はメソッドが1つなので、数十の型がこれを実装しており、io.Reader を受け取る関数はそのすべてで動きます。

package main

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

func countBytes(r io.Reader) (int64, error) {
	return io.Copy(io.Discard, r)
}

type Temp float64

func (t Temp) String() string { return fmt.Sprintf("%.1f°C", float64(t)) }

func main() {
	n1, _ := countBytes(strings.NewReader("hello"))
	n2, _ := countBytes(bytes.NewBufferString("hello, gopher"))
	fmt.Println(n1, n2)

	var sb strings.Builder // an io.Writer
	fmt.Fprintf(&sb, "%d + %d = %d", 2, 2, 4)
	fmt.Println(sb.String())

	fmt.Println(Temp(21.5)) // fmt calls String()
}

Goのことわざに「インターフェースが大きいほど、抽象化は弱くなる」というものがあります。大きなインターフェースは小さなものを組み合わせて作ります。io.ReadWriter は Reader と Writer を合わせたもので、インターフェースを別のインターフェースに埋め込んで書きます。

any：空のインターフェース

interface{} はメソッドを持たないので、どの型もこれを満たします。Go 1.18で別名として any が追加され、両者はまったく同じです。

package main

import "fmt"

func main() {
	var v any

	v = 42
	fmt.Printf("%v %T\n", v, v)

	v = "text"
	fmt.Printf("%v %T\n", v, v)

	v = []int{1, 2}
	fmt.Printf("%v %T\n", v, v)

	items := []any{1, "two", 3.0, nil}
	fmt.Println(len(items))

	if s, ok := v.([]int); ok {
		fmt.Println("slice of len", len(s))
	}
}

any の値は何でも保持できますが、型アサーションや型スイッチで具体的な型を取り戻すまでは、ほとんど何もできません。型の集合がわかっているなら、本物のインターフェースかジェネリクスを使いましょう。any が適しているのは、形のわからないJSONのデコード結果のような本当に動的なデータや、表示の場面です。

インターフェースの値に入っているもの

インターフェースの値は、動的な型と動的な値のペアです。var s Shape = Rect{3, 4} は型 Rect と値のコピーを保存します。s.Area() を呼ぶと、実行時に Rect のメソッドが検索されます。

インターフェースが nil になるのは、両方が空のときだけです。このルールが、Goで最もわかりにくいバグを引き起こします。

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

インターフェースにnilポインタを格納すると、nilでないインターフェースになります。

package main

import "fmt"

type MyError struct{ Msg string }

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

func validate(ok bool) error {
	var err *MyError // nil pointer
	if !ok {
		err = &MyError{"invalid input"}
	}
	return err // BUG: returns a non-nil error even when ok is true
}

func validateFixed(ok bool) error {
	if !ok {
		return &MyError{"invalid input"}
	}
	return nil
}

func main() {
	err := validate(true)
	fmt.Println(err == nil) // false
	fmt.Printf("%T %v\n", err, err == (*MyError)(nil))

	fmt.Println(validateFixed(true) == nil) // true
}

出力：

false
*main.MyError true
true

validate(true) は、型 *MyError と値 nil を保持する error インターフェースを返します。インターフェースは型を持っているので nil と等しくなく、呼び出し側の if err != nil の分岐が実行されます。そこで err.Error() を呼ぶと、nilレシーバーのフィールドへのアクセスでpanicします。

直し方は簡単です。変数を具体的なポインタ型ではなく error として宣言するか、成功の経路ではリテラルの nil を返します。結果が error の関数から、具体的なエラーのポインタ型を返してはいけません。同じ罠はエラーに限らず、あらゆるインターフェースに当てはまります。

型がインターフェースを実装しているか確認する

実装のチェックは、値がインターフェースに代入される場所で行われます。まだどのコードもそうしていなければ、メソッドのシグネチャの間違いは気づかれません。パッケージレベルでのブランクへの代入で、チェックを明示的にできます。

var _ io.Writer = (*LogWriter)(nil)
var _ fmt.Stringer = Temp(0)

実行時のコストはかかりません。*LogWriter が Write(p []byte) (int, error) ではなく Write(p []byte) error を持っていれば、ビルドが失敗します。

cannot use (*LogWriter)(nil) (value of type *LogWriter) as io.Writer value in variable declaration: *LogWriter does not implement io.Writer (wrong type for method Write)
		have Write([]byte) error
		want Write([]byte) (int, error)

ポインタレシーバーとインターフェース

メソッドがポインタレシーバーを持つと、そのメソッドを持つのはポインタ型だけです。*Counter はそれでインターフェースを満たしますが、Counter は満たしません。コンパイラは Counter does not implement Incrementer (method Inc has pointer receiver) と言います。インターフェースには &Counter{} を格納します。メソッドセットについてはメソッドのページで説明しています。

インターフェースを受け取り、構造体を返す

Goのよく知られた指針です。関数はインターフェースの引数を受け取り、具体的な型を返すべきです。

• インターフェースを受け取る と、呼び出し側はテスト用の偽物を含め、合うものなら何でも渡せます。データを読む関数は *os.File ではなく io.Reader を受け取るべきです。
• 具体的な型を返す と、呼び出し側はそのすべてのメソッドとフィールドを使え、nilインターフェースの罠も避けられます。os.Open は io.Reader ではなく *os.File を返します。

関連する習慣として、インターフェースは実装する側ではなく使う側で定義します。サービスがユーザーを Get(id) できるものを必要とするなら、サービスのパッケージにメソッド1つのインターフェースを宣言し、データベースのパッケージは構造体を公開するだけにします。

package main

import (
	"errors"
	"fmt"
)

// Declared by the consumer, with only what it needs.
type UserGetter interface {
	GetUser(id int) (string, error)
}

func greet(db UserGetter, id int) string {
	name, err := db.GetUser(id)
	if err != nil {
		return "hello, stranger"
	}
	return "hello, " + name
}

// A fake for tests or examples: no mocking library needed.
type fakeDB map[int]string

func (f fakeDB) GetUser(id int) (string, error) {
	if n, ok := f[id]; ok {
		return n, nil
	}
	return "", errors.New("not found")
}

func main() {
	db := fakeDB{1: "Ana"}
	fmt.Println(greet(db, 1))
	fmt.Println(greet(db, 2))
}

インターフェースの値を比較する

2つのインターフェースの値は、動的な型が同一で、動的な値が等しいときに等しくなります。動的な型が比較できないもの（スライス、マップ）だと、== はコンパイルできますが実行時にpanicします：runtime error: comparing uncomparable type []int。

よくある間違い

• 型付きのnilポインタをインターフェースとして返す。 リテラルの nil を返します。
• 早すぎるインターフェース。 まず具体的な型を書きます。2つ目の実装やテストが必要になったらインターフェースを追加します。
• インターフェースへのポインタ。 *io.Reader が正しいことはほとんどありません。ポインタを格納すれば、インターフェースはすでにポインタを保持しています。
• 大きなインターフェース。 メソッドが10個あるインターフェースは実装も偽物作りも大変です。分割しましょう。