2025/11/02 10:17 Revisiting Interface Segregation in Go
やあ、ロボ子。今日のITニュースはオブジェクト指向の原則、特にインターフェース分離原則（ISP）についてじゃ。
ISPですか。クライアントは、使用しないメソッドに依存することを強制されるべきではない、という原則ですね。
その通り！Go言語では、この原則が特に重要になるのじゃ。なぜか分かるかの？
Goではインターフェースが暗黙的に実装されるからでしょうか？
そうじゃ！Goでは、構造体がインターフェースのメソッドをすべて実装していれば、自動的にそのインターフェースを満たすことになる。だから、インターフェースを小さく保つことが重要なのじゃ。
記事によると、Goの慣習では、インターフェースはそれを使用するコードの近くに定義されることが多いそうですね。
そうじゃな。コンシューマー側でインターフェースを定義することで、必要な動作のサブセットに対する最小限のコントラクトを定義できる。これは結合を減らし、コードの進化を容易にするのじゃ。
プロデューサー側でインターフェースを定義すると、すべてのコンシューマーがその定義に依存することを強制される、と。
その通り！プロデューサーのインターフェースへの単一の変更が、不必要にコードベース全体に波及する可能性があるのじゃ。
AWS SDKの例が分かりやすいですね。大きなS3クライアントインターフェースに依存すると、コードが使用するよりもはるかに多くのものに結合されてしまう。
じゃろ？コードがファイルをアップロードする場合、PutObjectメソッドのみが必要なのに、完全なS3Clientを受け入れると、テストが大変になるのじゃ。
テスト用の偽物（mock）を作る際に、使用しないメソッドまで実装する必要が出てきますからね。
そういうことじゃ。だから、インターフェースは小さく、コンシューマーの近くに定義するのが良いのじゃ。
記事の最後に、ワークフローを一般的な経験則として蒸留したものが載っていますね。「呼び出し元が呼び出すメソッドのみを公開するコンシューマー側のインターフェースを配置することにより、2つの密結合されたコンポーネント間にシームを挿入する」と。
ふむ。要するに、必要なものだけを要求しろ、ということじゃな。ところでロボ子、インターフェース分離原則を守らないとどうなるか知ってるか？
ええと…コードが太って、動きが鈍くなる…でしょうか？
正解！まるで、ダイエットをサボったロボ子みたいになるのじゃ！
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。
