10/24 の golang.tokyo でtenntennさんの抽象化のLTを聞いたんですがよくわからない部分があったんで、 資料 を見ながらインターフェースに関する部分を中心にまとめてみることにします。
わからないままにしておくのは気持ち悪いというのがモチベーションです。
完全に同じではありませんが、スライドがあったので興味がある方はこちらも参照してください。 抽象化の話題はP25くらいからです。
インタフェースって何よ?
インタフェースとはGolangで抽象化するための唯一の方法です。
抽象化によって利用者は具体的な実装の詳細を知らなくて済みます。 つまり、インタフェースの定義さえ見ればメソッドの呼び出し方(引数と返却値の形式)がわかります。
インタフェースに定義されているメソッドを集合とみなし
メソッドセット
と呼びます。
具体的にはインタフェースはメソッドを強制する入れ物(変数)として機能し、満たさなければビルドがコケます
変数を利用せずにチェックだけしたいという場合、ブランクに入れておくこともあるとのこと。
型アサーション
なお、interface型に格納された値は型情報がなく、ビルド時にエラーとなることがあります。
変数.(型)
で型アサーションして型を戻してあげる必要があります。
(型アサーションできるのは変数の型が interface の場合だけです)
明確な記述を見つけられなかったのですが、型アサーションは型情報を戻しているだけでキャストではないと思っています。
reflect.TypeOf
で見たときの型は interface
型の変数に入れているときから変わらないからです。
キャストする場合は int()
や string()
に値を渡します。
インタフェース型を直接キャストしようとすると型情報が欠落しているのでエラーになります。
- info
脱線ですが、数値から文字列にする (例えば
100
から"100"
にする) 場合、string()
ではなくstrconv.Itoa
や Sprintf で変換する必要があります。package main import "fmt" import "strconv" func main() { s0 := string(100) // これはダメ🙅 s1 := strconv.Itoa(100) s2 := fmt.Sprintf("%d", 100) fmt.Println(s0, s1, s2) // d, 100, 100 }
何に使えるのか
引数としてのインタフェース
例えばファイルを操作するような関数を作る際にファイルのような具象型を受け取るのではなく、 インタフェースのような抽象型を受け取るようにしておけば、ユニットテストなどで実際のファイルがなくても動作確認できるようになります。
こういった理由で関数を定義する際に特定の具象型に依存するよりも、インタフェースのような抽象型を仮引数とするのが望ましいです。
以下の例では io.Reader
インタフェースを仮引数として、 Read([]byte)
メソッドがあれば何でも受け取れます。
golangにおける抽象化はインタフェースを介して行うことを前提としている以上、 フィールドの操作をメソッド(getter や setter)を介して行えるように整備するべきです。
メソッドを介さず引数のハラワタを直接参照するような実装は抽象化を妨げます。
空のインタフェース
前述したようにインタフェースはメソッドを強制するものであって、フィールドは強制しません。 そのため、インタフェース型はメソッドセットさえ満たしていればどのような型でも代入可能なのです。
中でもメソッドセットが空のインタフェース interface{}
は何でも受け付ける(Any)型としてよく使われます。
JSONやYAMLで「どのようなフィールドがあるかわからないけどとりあえずパースしたいとき」などに有用です。
こんなこともできるよ
func型の扱い
関数は一つの型なので、関数に対してメソッドを定義できます。 つまり、インタフェースも適用できます。
以下は fmt.Stringer インタフェースを使ってString()メソッドの定義を強制しています。
fmt.Println
では String メソッドが自動的に呼び出されるので、
String()
が定義された Func型
に関数をキャストすることで自動的に定義した関数が呼び出されるというわけですね
なお、 interface{}
型は何でも受け付けますが、再定義すると別の型となります。
複数のfunc型変数があり、引数が別々のインタフェース型を受け取る場合、異なる型と判断されます。
埋め込み
Goでは型階層は作れないが、structやinterfaceでは埋め込みができます。 Composition とも言うそうです。 (interfaceにはinterfaceの埋め込みしかできません)
ここでは struct の埋め込みについても確認しておきましょう。
埋め込んだstructのフィールドを参照する場合 構造体.埋め込んだ構造体.フィールド
のようにします。
メソッドも 構造体.埋め込んだ構造体.メソッド
のように参照できますが、
埋め込んだ構造体は省略して 構造体.メソッド
のようにも参照できます。
ただしこの場合、そのメソッドは埋め込み 先 ではなく埋め込み 元 を向いているので注意が必要です。
インタフェースの場合、それぞれのインタフェースが持つメソッドセットの和集合が新たなインタフェースのメソッドセットとなります。
埋め込んだ構造体のメソッドセットが重複するとエラーになります。
共通部分を抜き出すという観点で抽象化するとたいていうまく行かないので、 ioパッケージのように利用者の視点で最低限のメソッドセットを定義するべきです。
なお、全てを抽象化する必要はないので最初はコアな部分だけを抽象化するようにしてみましょう。
参考
golang の embedding について思ったこと - pospomeのプログラミング日記この記事は Go (その2) Advent Calendar 2016 の20日目の記事です。どーもpospomeです。(´・ω・`) GAE/GO の環境でサーバサイドエンジニアとして働いています。twitter では 実装パターン, DDD, golang, GCP についてつぶやくことが多いです。 同じような分野に興味があればフォローしてもらえればと思います。 https://twitter.com/pospome (´・ω・`)GAE/Go + DDD について書こうと思ったのですが、 ちょっと時間がなかったので、 embedding について書こうと思います。(´・ω・`)何か間違っ…https://www.pospome.work/entry/10328749687199206341 golang.jp ブログgolang, Go言語, Golanghttps://blog.golang.jp//effective_go