コードをテストしやすくするために、具体的な型の代わりにインターフェイスを使用することに重点が置かれています。私はsql DBやRowsのようなパッケージではこれがなぜ行われなかったのだろうと思います。これらの依存関係を模擬するために私は独自のインターフェースを作成して、ユニットテスト（統合テストではない）を書くことができなければなりませんでした。 DBのコードはそのようにテストされていますか？GOのデータベースタイプがインタフェースでない理由
具体的な型の代わりに公開APIにインターフェイスを公開すると、インターフェイスにメソッドを追加するときに他の人のコードが破損する危険性が高まります。
たとえば、os.Fileを参照してください。 os.Fileがインタフェースであれば、17個のパブリックメソッドを持つインタフェースになります。 18番目のメソッドを追加すると、os.Fileインターフェイスを実装した独自の型を定義したすべての人が壊れてしまいます。対照的に、現在のos.File構造体に18番目のメソッドを追加しても、io.Reader,io.Writerまたはos.Fileのメソッドのサブセットを定義するその他のインタフェースを取るメソッドは破られません。また、io.Readerとio.Writerインターフェイスをモックするテストコードを破ることもありません。
他の人に独自の実装を定義させたい場合は、パブリックAPIにインタフェースを公開してください。それ以外の場合は、具体的な型を公開し、必要なメソッドのサブセットのみを使用して、具体的な型で実装された独自のインタフェースを定義できるようにします。
誰でもどこのタイプのインタフェースもGoに作成できます。つまり、使用しないインタフェースを宣言する必要はありません。あなたが気付いたように、既存のインターフェースがなかったという事実が、あなたが望むものを作成するのを妨げていないということです。 –
確かに、私はそれを得る。しかし、私は他の人が具体的なタイプを模擬するのをより簡単にするために、インタフェースの使用を強調している多くのゴーファーに出くわします。たぶん私はこれを考えすぎているかもしれない。ありがとう。 –
@AmirKeibi：インターフェースは、モックをもっと簡単に、真実にするのですが、それはパッケージのメンテナーが完全なインターフェースベースのパッケージを作成することになっているわけではありません。 'database-sqlmock '（https://github.com/DATA-DOG/go-sqlmock）のように' database/sql'を簡単にモックできるパッケージがあります。 –