Goのインターフェイスは、問題を解決する方法を形成する言語の特徴的な機能の1つです。他の言語のインターフェイスと似ていますが、Goのインターフェイスには依然として重要な違いがあります。これにより、最初はインターフェイスが過剰に再利用され、その使用方法とタイミングに関する混乱が生じます。これは正常な動作ですが、Goのインターフェイスの特性、配置方法、重要性、Goのインターフェイスタイプと構造タイプの直交性の意味を理解してみましょう。

この記事では、次のことを学習します。

Javaのインターフェースとの違いは何ですか
これらの違いの重要かつ非自明な結果
インターフェースがボンネットの下にどのように配置されているか
空のインターフェイスを覚えてください（インターフェイス{}）
ジェネリックに関する神聖なトピックに触れる
誰が、なぜインターフェースを作成する必要があるかを見てみましょう
インターフェースを乱用せずに生活を始めることを学ぶ

（ Svitlana Agudovaによるアートワーク）

直交性

それでは、最初の重要なポイントから始めましょう。これは非常に理解しやすいです- インターフェースが動作を決定します 。この点で、GoのインターフェースはJavaのインターフェースと実質的に違いはありません。

たとえば、Javaでのインターフェースとその実装は次のとおりです。

public interface Speakable { public String greeting = "Hello"; public void sayHello(); } public class Human implements Speakable { public void sayHello() { System.out.println(Speakable.greeting); } } Speakable speaker = new Human(); speaker.sayHello();

Goの例：

 type Speaker interface { SayHello() } type Human struct { Greeting string } func (h Human) SayHello() { fmt.Println(h.Greeting) } ... var s Speaker s = Human{Greeting: "Hello"} s.SayHello()

http://play.golang.org/p/yqvDfgnZ78

一見、違いは純粋に表面的なものです。

Javaでは、キーワードpublic / protected / etcが使用されます。Goでは、メソッド名の最初の文字が可視性を決定します
Javaでは、多くの場合、-able後置記号を使用してインターフェイスを呼び出します。Goでは、-er後置記号（Sender、Reader、Closerなど）を使用するのが一般的です
Javaでは、インターフェイスを実装するためにクラスが使用され、Goでは、メソッドを持つ構造が使用されます。
Javaインターフェース実装では明示的に（ implements ）、Goでは暗黙的に（ダックタイピング）が示されます
Javaでは、インターフェイスとクラスの両方にデータとメソッドの両方を含めることができますが、Goでは、インターフェイスにデータを含めることはできず、メソッドのみを含めることができます。

しかし、これらの違いのいくつか、特に最後の2つは重要です。それらについて詳しく見ていきましょう。

暗黙的な実装

カモのように見え、カモのように泳ぎ、カモのように鳴くなら、おそらくカモです。

Goでは、メソッドを宣言したという事実だけで、メソッドを持つ構造体がインターフェイスを満たします。これは小さなプログラムや人為的な例では特に重要ではないようですが、他のクラスに何度も継承されているクラスを変更する前によく考えなければならない大規模プロジェクトでは重要です。

さまざまなインターフェイスを簡単かつ単純に暗黙的に実装できるため、可能なすべてのインターフェイスを事前に検討し、多重継承に埋もれることなく、プログラムを簡単に成長させることができます。これは、Goが大規模プロジェクトでの生活を楽にするために考案された言葉です。

これの重要ですぐに明らかな違いは、最終的にプログラムのアーキテクチャを構築する方法です-JavaまたはC ++では、ほとんどの場合、抽象クラスとインターフェイスを宣言することから始めて、特定の実装に進みます。それに対して、Goでは、最初に特定の型を記述し、データとメソッドを定義します。実際に動作を抽象化する必要がある場合にのみ 、別のインターフェイスを作成します。繰り返しになりますが、この違いの規模は、大規模プロジェクトでより明確になります。

データと行動

Javaでクラスとインターフェースの両方がデータと動作の両方を記述する場合、Goではこれらの概念は根本的に区別されます。

構造はデータを保存しますが、動作は保存しません。 インターフェイスは動作を保存しますが、データは保存しません。

Hello string

などの変数をインターフェイスに追加する場合は、何か間違ったことをしていることを知っておく必要があります。構造体にインターフェイスを埋め込む場合、動作とデータが混乱します。 Javaの世界ではこれは正常ですが、Goでは抽象化の明確さを形成するため、これは重要な区別です。

上記の例では、スピーカーは動作を説明していますが、このインターフェイスを実装する人が正確に言うべきことを言っていません。繰り返しになりますが、GoコードのインターフェイスとしてのSpeakerは、Humanの特定の実装が記述された「ベースクラス」としてではなく、 他のtypeによって実装される実際的な必要性から生まれました 。

「振る舞い」と「データ」の抽象化を明確に区別し始めるとすぐに、Goでインターフェースを使用する目的と適切な方法をより明確に理解し始めることを理解することが重要です。 人間と話者は直交しています。人間は別の10個のインターフェイス（Walker、Listener、Player、Programmerなど）を簡単に満たすことができ、スピーカーは他のパッケージ（ロボット、動物、コンピューターなど）からでも数十種類に満足できます。そして、これらすべては、最小限の構文オーバーヘッドで行われます。これも、大規模なコードベースでは重要です。

インターフェースデバイス

Humanが同時にスピーカーになり、さらに多くのインターフェイスになると同時に、直交する方法を理解していない場合は、さらに深く掘り下げて、インターフェイスがフードの下にどのように配置されているかを見てみましょう。 Go 1.5（それ自体はGoで記述されています）では、インターフェイスタイプは次のようになります。

src /ランタイム/ runtime2.go

 type iface struct { tab *itab data unsafe.Pointer }

ここで、tabはインターフェイステーブルへのポインタ、またはitableは、インターフェイスを満たすために使用されるいくつかのタイプメタデータとメソッドのリストを格納する構造です。

データ-特定の（静的）タイプの実際の変数を示します。

明確にするために、次のようにコードをわずかに変更します。

 h := Human{Greeting: "Hello"} s := Speaker(h) s.SayHello()

http://play.golang.org/p/AB0ExdGN0W

イタブル

この図は、 sが2つのポインターで構成されていることを示しています。最初のポインターは特定のペア（静的型Human、スピーカーインターフェイス）のitableを指し、他方はHumanの元の値のコピーを指します。

 h := Human{Greeting: "Hello"} s := Speaker(h) h.Greeting = "Meow" s.SayHello() //  "hello"

イタブル

itableについて少し説明します。このテーブルは、インターフェイスと静的な型のペアごとに一意であるため、コンパイル段階での計算（初期バインディング）は非合理的で非効率的です。

代わりに、コンパイラは各静的タイプのメタデータを生成します。これには、とりわけ、そのタイプに実装されたメソッドのリストが格納されます。同様に、メタデータは、各インターフェイスのメソッドのリストで生成されます。これで、プログラムの実行中に、ランタイムGoが特定のペアごとにitableをオンザフライで計算できます（遅延バインディング）。このitableはキャッシュされるため、計算ミスは1回しか発生しません。

これを知って、Goがコンパイル時に型の不一致をキャッチするのは明らかですが、実行時にインターフェイスにキャストします。インターフェース型への変換のエラーを安全にキャッチするために、カンマ-ok構文が存在することを忘れないでください-if if s, ok := h.(Speaker); !ok { ... }

if s, ok := h.(Speaker); !ok { ... }

。

 var s Speaker = string("test") // compile-time error var s Speaker = io.Reader // compile time error var h string = Human{} // compile time error var s interface{}; h = s.(Human) // runtime error

空のインターフェース{}

ここで、空のインターフェイスと呼ばれるinterface{}

思い出してみましょう。これは、どのタイプでも一般に満たされます。空のインターフェースにはメソッドがないので、それを計算して保存する必要はありません-静的型に関するメタ情報で十分です。

したがって、メモリでは、空のインターフェイスは次のようになります。

空のインターフェイスを使用するたびに、覚えておいてください。それは何の意味もないこと。抽象化なし。これは、特定のタイプに対する見えないマントであり、特定のタイプをあなたから隠し、動作を理解することはできません。そのため、最も極端な場合に空のインターフェイスを使用する必要があります。

インターフェイスとジェネリック

ご存知のように、Goでは、汎用コンテナは言語にあるもの（スライス、マップ）によってのみ制限されます。 Goは、インターフェイスを使用して汎用アルゴリズムを作成できます。ここでの古典的な例は、そのようなバイナリツリーの実装です。

 type Item interface { // Less tests whether the current item is less than the given argument. // // This must provide a strict weak ordering. // If !a.Less(b) && !b.Less(a), we treat this to mean a == b (ie we can only // hold one of either a or b in the tree). Less(than Item) bool }

btree.Itemタイプは、値の比較を可能にする単一のLessメソッドが定義されているインターフェースです。アルゴリズムの内部では、Item-sからスライスが使用されます。アルゴリズムは、静的型が何であるかを深く気にしません。必要なのは、値を比較できることだけです。これがLess（）メソッドから得られるものです。

 type MyInt int func (m MyInt) Less(than MyInt) bool { return m < than } b := btree.New(10) b.ReplaceOrInsert(MyInt(5))

同様のアプローチは、 sortパッケージの標準ライブラリで見ることができます-sort.Interfaceインターフェースを満たす任意の型は、パラメーターとしてsort.Sort関数に渡され、ソートされます：

 type Interface interface { // Len is the number of elements in the collection. Len() int // Less reports whether the element with // index i should sort before the element with index j. Less(i, j int) bool // Swap swaps the elements with indexes i and j. Swap(i, j int) }

例：

 type Person struct { Name string Age int } // ByAge implements sort.Interface for []Person based on // the Age field. type ByAge []Person func (a ByAge) Len() int { return len(a) } func (a ByAge) Swap(i, j int) { a[i], a[j] = a[j], a[i] } func (a ByAge) Less(i, j int) bool { return a[i].Age < a[j].Age } ... people := []Person{ {"Bob", 31}, {"John", 42}, {"Michael", 17}, {"Jenny", 26}, } sort.Sort(ByAge(people))

インターフェースの乱用を止めて生活を始める方法

Goの多くの新参者、特に動的型付けを使用する言語から切り替えた人は、インターフェイス型で特定の型を使用しない方法を確認しています。「すべてをインターフェイス{}でラップします」と、開発者は考えて、ほとんどの場合は空のインターフェイスでプログラムを汚染します。

しかし、ここでの黄金のルールは次のように聞こえます。常に特定のタイプで動作し、必要な場合にのみインターフェイスを使用し、そうでない場合は最も極端な場合は空のインターフェイスを使用します。

たとえば、データを表示するダッシュボードを作成します。このデータは、1つのソースからはfloat64値の形式で、別のソースからは文字列（「失敗」、「成功」など）の形式で取得されます。チャンネルを介して値を受け取り、それらを画面に表示する関数をどのように実装しますか？

ほとんどの初心者は言うでしょう-簡単です、空のインターフェース（ chan interface{}

）のチャネルを作成し、それを通過させてから、型にキャストしましょう：

 func Display(ch chan interface{}) { for v := range ch { switch x := v.(type) { case float64: RenderFloat64(x) case string: RenderString(x) } } }

そして、そのようなコードには存在する権利もありますが、より美しく行うことができます。私たちの場合、float64とstringの共通点について考えてみましょう。両方をレンダリングする必要があるという事実は、Renderメソッドでインターフェースを作成するための候補です。試してみましょう：

 type Renderer interface { Render() }

さらに、メソッドを標準型にアタッチできないため（これは既に別の型になります）、MyFloatとMyStringを作成します。

 type ( MyFloat float64 MyString string )

そして、それぞれにRenderメソッドを実装し、Rendererインターフェイスを自動的に満たします。

 func (f MyFloat) Render() { ... } func (s MyString) Render() { ... }

これで、 Display

関数は次のようになります。

 func Display(ch chan Renderer) { for v := range ch { v.Render() } }

もっと美しく簡潔ですよね？ここで、Displayでレンダリングできるようにする必要がある別のタイプを追加する場合、Renderメソッドを追加するだけで、他に変更する必要はありません。

そして、重要なことは、このコードは物事の実際の状態を反映しています-インターフェースの傘の下で型をそれらの一般的な振る舞いに従って結合します。この動作はデータ自体に直交しており、現在ではコードに反映されています。

インターフェースサイズ

Go Proverbsの信条は次のとおりです。 「インターフェイスが大きくなるほど、抽象化が弱くなります。」上記の例では、メソッドが1つだけの小さなインターフェイスは、「レンダリングされる値」の抽象化を非常に明確に説明するのに役立ちました。たとえば、文字列に固有の一連のメソッドを使用してインターフェイスを作成した場合、float64でそれを使用することはできず、新しいものを考え出す必要があります。

Goでは、ほとんどのインターフェイスに1-2メソッドが含まれています。しかし、これはもちろん禁止ではありません-何百ものメソッドを備えたインターフェイスが絶対に必要な場合（たとえば、一部のモック向け）-これも問題ありません。

誰といつインターフェースを作成する必要がありますか？

興味深い議論がありましたが、その間に次のような声明が出されました- 「Goのすべてのライブラリはインターフェイスをエクスポートする必要があります 。」たとえば、ライブラリ機能をモックしたい場合は、このインターフェイスをスタブに実装してテストするだけで十分です。

そうではありません。各ライブラリはインターフェースをエクスポートすべきではなく、誰がインターフェースを作成するかを決定するための一般的なルールは次のように説明できます。

インターフェイスは、プロデューサーではなく、コンシューマーによって作成されます。

ライブラリがStaticType1を実装している場合、そのためのインターフェイスを作成する必要はありません。ライブラリのコンシューマとして、型の動作を抽象化し、ロックしてStaticType2を作成する場合は、コード内でStaticType1と交換可能にする必要があります。自分でInterfaceを実装し、自分で使用します。これはあなたの仕事です-あなたは言語でそれを解決します。

上記のソートライブラリでは、sort.Sort関数が機能するためにsort.Interfaceインターフェイスが必要です。つまり、ライブラリ自体がそのコンシューマです。

まとめ

Goタイプシステムは、他の言語から切り替えるときに、その単純さの点で依然としていくつかの問題を引き起こします。誰かがそれをSOLID原則に詰め込もうとしている、誰かがクラスとの類似性を構築しようとしている、誰かが特定の型を悪であり、ジェネリック型が良いと考えている、これは初心者にとっていくつかの困難を生み出します。しかし、これは正常であり、ほとんどすべてがそれを通過するので、この記事でGoのインターフェースの本質、目的、目的を少し明らかにしてほしいと思います。

要約すると、3つのポイント：

インターフェイスは動作を定義し、静的型はデータを定義します
インターフェースが大きいほど、抽象化が弱い
インターフェイスは通常、消費者によって作成されます。

インターフェースクラッシュコースに行く

直交性