1

私は最近、Go プログラミング言語が好きになりました。これまでのところ素晴らしいと思いますが、インターフェイスを理解するのに本当に苦労しています。私はそれらについてかなり読んだことがありますが、それでも私には非常に抽象的です.

以下のインターフェースを使用する簡単なコードを書きました。

package main

import (
  "fmt"
  "math"
)

type Circer interface {
    Circ() float64
}

type Square struct {
    side float64
}

type Circle struct {
    diam, rad float64
}

func (s *Square) Circ() float64 {
    return s.side * 4
}

func (c *Circle) Circ() float64 {
    return c.diam * math.Pi
}

func (c *Circle) Area() float64 {
    if c.rad == 0 {
        var rad = c.diam / 2
        return (rad*rad) * math.Pi
    } else {
        return (c.rad*c.rad) * math.Pi
    }
}

func main() {

    var s = new(Square)
    var c = new(Circle)

    s.side = 2
    c.diam = 10

    var i Circer = s

    fmt.Println("Square Circ: ", i.Circ())

    i = c

    fmt.Println("Circle Circ: ", i.Circ())
}

Circer インターフェースの目的がよくわかりません。メソッドは既に作成されており、Circer をラッパーとして使用するのではなく、構造体でメソッドを直接呼び出すだけで 2 行のコードを節約できました。

足りないものはありますか？インターフェイスの使い方が間違っていませんか? ヘルプや例をいただければ幸いです。

4

3 に答える 3

2

「私たちは、疑いと不確実性の厳密に定義された領域を要求します!」 - ダグラス・アダムズ、『銀河ヒッチハイク・ガイド』

Go のインターフェイスを理解するには、まず、一般的にインターフェイスをプログラミングする理由を理解する必要があります。

何をどのように分離するか

インターフェイスを使用して、実装の詳細を抽象化の背後に隠します。詳細 (つまり、方法) は抽象化よりも変更される可能性が高く、変更がプログラム全体に波及することなくアプリケーションを拡張および変更できるため、これらの詳細を隠したいと考えています。消費者が具象型ではなくインターフェイスに依存する場合、インターフェイスの背後にある実装の詳細からプログラムを分離しているため、消費者が変更から保護され、アプリケーションのテスト、拡張、および保守が容易になります。

Golang インターフェイス

Go には非常に強力な Interface 実装があります。ほとんどの言語と同様に、抽象化を介してオブジェクトの動作を指定する方法を提供するため、抽象化が使用されるあらゆる場所でその抽象化の実装を使用できますが、Go では、concretion が実装することを明示的に宣言する必要はありません。 Go がこれを自動的に処理するように、特定のインターフェイス。

明示的な宣言要件を削除すると、次のような興味深い影響があります。適切な抽象化を特定するのに役立つように、プログラムにインターフェイスを表示させることができます。実装を発見したときにすべての実装に注釈を付ける必要はありません。これは、テスト用に作成されたインターフェイスが実装コードを汚染する必要がないことも意味します。さらに、インターフェイスと実装者の間に明示的な関係がないため、実装者にはその方向での依存関係/カップリングはありません。

Circer インターフェイスの例

あなたが提供した例では、実装（concretion）にバインドする代わりに、インターフェイスを使用することの複雑さと「認知的負荷」を回避する方が確かに簡単で簡単です。ほとんどの些細な例では、インターフェースを使用することはエンジニアリングより独断的に思えるかもしれません。

概要

インターフェースは、アプリケーションを分離して時間の経過とともに成長しやすくするための強力な方法です。変更/バリエーションが予想される場合(およびその変更/バリエーションからアプリケーションを保護する必要がある場合)、インターフェイスを作成して依存することは、正しい方向への一歩です。

多くのための...

この「良い」Go Object Oriented Design の投稿を参照してください。

また、抽象化の影響を検討し、依存関係と変更を管理する際に開始するのに最適な場所であるため、 SOLID 設計原則を確認してください。

于 2013-09-17T19:13:38.170 に答える