ライブラリとして公開したGoのinterfaceを変更するのは難しいと言う話 - 焼売飯店

昨日Twitterに書いた内容に、sivchariさんとhajimehoshiさんからリプライをいただいたので、備忘録的にまとめておきます。 発端 interface型と非interface型の後方互換性について interface型を公開した場合 1. メソッドの追加 2. メソッドのシグニチャの変更 3. メソッドの削除 公開されたinterface型を変更する場合の後方互換性についてのまとめ 非interface型を公開した場合 1. メソッドの追加 2. メソッドのシグニチャの変更 3. メソッドの削除 公開された非interface型を変更する場合の後方互換性についてのまとめ その他の後方互換性を崩さない機能拡張のパターンの紹介 他から実装できないinterfaceにする interfaceを合成する 内部用のinterfaceを分け、構造体型を公開する まとめ 発端 昨日、フュ

[codehex]

context の interface はテスト目的じゃなくて、振る舞いが違う構造体同士をラップしていくためには interface にするしかなかったんじゃないのかなーと思う これは error インターフェースでもみられるパターン

[yujiorama]

利用者はバージョン指定してgo getしてるはずだから、シグネチャを変更するならライブラリは素直にメジャーバージョンするものだと思ってた

[t_f_m]

2023年1月の記事

[arx0balest]

type errorで破壊的変更を静的に検知できるのが静的型の良いところの1つじゃなかったの？Rubyみたいなゴミに煽られるレベルで情けない話だぞ。

[turanukimaru]

自分のプロジェクトでも interface に関数を追加するとテスト用モックが真っ赤になるので公開関係なく interface 変更は悪手。interface を作り足せばいいだけなので問題という訳ではない。

[asuka0801]

go moduleの都合上goのメジャーバージョンはなるべく上げたくない。v1.0.0になった時点でinterfereの変更は無い（ある場合はフォークして別のライブラリとして公開する）のが良いんじゃないかなぁ。

[zentarou]

interfaceは利用側で定義するだけが平和よな