7 Common Interface Mistakes in Go
ほかの言語に見られる interface と Go におけるそれはだいぶ違うよというハナシ 1つの実装しかなければ interface を使うな、はそのとおりだと思う
The bigger the interface, the weaker the abstraction.
inteface は小さければ小さいほど利便性が高い、典型的には stringer, error なんかが挙げられる
標準パッケージにおいてもメソッドの最大数は3つ
code:io.go
type ReadWriteCloser interface {
Reader
Writer
Closer
}
それは struct ではダメなのか考える
途中DIPにおけるimplするパッケージ内にinterfaceを置かず、interfaceへ依存するパッケージに置けというのは場合によりけりな気がする https://gyazo.com/4bbf11ce283494da1f2d70f47a24d598
よくあるのはテスタブルにしておきたくて DI とセットでみたいな構成だが、テストのために interface を使うなとある
これは実装が1つしかなければ interface を使うなという筆者の主張にも追随する
tkdn.icon それは本当にそうなのか?
こういうときはだいたいテスト用の Mock とアプリケーションコードがセットになっている
e.g. interface から gomockによるコード生成なんかがそう 筆者が言いたいのはモックを使うことで、1つでよい概念が2つに増えるからであるという
“The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.” - Edsger Dijkstra
tkdn.icon gomockのようにコード生成されるような知識は開発者に認知負荷がかかるわけではないので別にいいんじゃないか。厳格なセマンティックレベルとかいうものを現実のソフトウェアに適用させることの潔癖姓は持たなくていいように思える