「抽象に依存せよ」が分からなかった新卒1年目の私が Goのインターフェースと和解するまで

「 想定する参加者層」
・実装への依存を避けるべき理由が腹落ちしていない学生・若手エンジニア
・Goのインターフェースを「どこに定義すべきか」迷いながら実装している方

「トーク概要」
開発の中で「ここは実装でなく、抽象に依存した方が良いんじゃない？」というレビューをもらった当時の私は、その真意を掴めていませんでした。

しかし、開発経験を重ね、テストやパッケージ構成の課題に向き合う中で、その指摘がGoのコードにおいて理にかなっていることに気づきました。

本セッションでは、新卒の私が、**「Goにおいてインターフェースに依存するメリット」**を理解するまでの過程をお話しします。
実務で直面した迷いと気づきをベースに、明日から使える判断基準を共有します。

「具体的に話す内容」
1. 実体への依存がなぜ単体テストを困難にするのか
・具体的なコードを例に、インターフェースを挟むことで単体テストが書きやすくなる理由をお話しします。

2. 新卒1年目で学んだ、インターフェースを使うべきタイミング
・なんでもインターフェースにするのではなく、「いつ導入すべきか」の自分なりの判断基準（境界づけ）についてまとめます。

「LTを通して得られること」
1. 「抽象に依存する」ことの具体的なメリット（テスト容易性・疎結合）
2. 自分のコードにいつインターフェースを導入すべきかの判断軸

Transcript

1. 「抽象に依存せよ」が分からなかった 新卒1年目の私が Goのインターフェースと和解するまで
2. 自己紹介 2 宮川 玄暉（@kurogenki0522） • 株式会社BuySell Technologies で バックエンド担当 • 25新卒 • 牛タンLOVE！！ 買取・査定 買取種別に応じた最適なシステム構築 Visit -訪問買取 - Store -店舗買取 - 買取 リユースプラットフォーム Cosmos 自社開発のリユース特化業務基幹システムでありサービス群の集合体
3. 新卒なので元気にいきます！！💪💪 3
4. 4 和解　＝
5. 自分なりの意図を持って インターフェースを使える状態 5 和解　＝
6. 覚えて帰って頂きたいこと 6 • 抽象に依存するとは？ • 抽象に依存して出来るようになること（2つ扱います！）
7. 早速ですが、皆さんはこのコードをどう思いますか？ 7
8. 早速ですが、皆さんはこのコードをどう思いますか？ 8 • 単体テストが 書きづらくない？ • NotifyUserは 抽象に依存させた方 がいいんじゃない？
9. • 何故テストが書きづらいの？ • 抽象に依存させる？ どうしてそうした方がいいんだ？ • そもそも抽象って何だ？ 9 経験の浅い自分にはこんな疑問がありました
10. 10 Q. そもそも抽象に依存するとは？
11. 11 A. 具体的な処理でなくインターフェースを 経由して参照する形にすること
12. コードで比較してみる 12 実体に依存しているパターン 抽象に依存しているパターン
13. コードで比較してみる 13 実体に依存しているパターン 抽象に依存しているパターン
14. 14 コードの違いはなんとなく分かった
15. 15 Q. 抽象に依存すると何が出来るようになるの？ メリットは何？
16. ① 参照する処理に影響されず、単体テストしやすくなる 16
17. 具体的な実装に依存すると • Sendメソッドの挙動に影響 されてしまう • NotifyUserに問題なくても、 Sendメソッドに問題あると テストが失敗してしまう ① 参照する処理に影響されず、単体テストしやすくなる 17
18. 抽象に依存した場合では？ 18
19. 抽象に依存すると • モックのSendメソッドを呼ぶ ことが可能 • Sendメソッドの実装に 影響されず、挙動を指定して テスト可能 ① 参照する処理に影響されず、単体テストしやすくなる 19
20. ② 処理を低コストで置き換えられる 20
21. 具体的な実装に依存した場合 • 各サービスに送信する メソッドを作る • userの存在確認をする ロジックが重複している ② 処理を低コストで置き換えられる 21 追加要件：ユースケース次第で、SlackかEmailのどちらかに通知したい 他のサービスにも送りたいとなった場合は、、、？
22. 抽象に依存した場合では？ 22
23. 抽象に依存した場合 • UserServiceに渡すnotifier を変えるだけで、送信先を 変更できる • 存在確認のロジックが 1箇所にまとめられる ② 処理を低コストで置き換えられる 23 追加要件：ユースケース次第で、SlackかEmailのどちらかに通知したい
24. ③ 使う側にインタフェースを配置する • インターフェースの肥大化を防ぎ、再利用性を高くするため ① いつインターフェースに切り出すか？ • 単体テストを書く際、参照するメソッドの影響を受けたくない場合 個人的にインターフェースを使う際に意識していること 24 ② 最初からインターフェースを作る前提で設計しない • 過度に抽象化したコードは読みづらくなってしまうという意見を本で見た ②や③が詳しく載っている本（https://book.impress.co.jp/books/1122101133）
25. まとめ（私がインターフェースと和解するまでの流れ） 25 1. 抽象という概念を知る 2. 「抽象に依存する場合」と「実体に依存する場合」の違いをコード ベースで知る 3. 抽象に依存した場合のメリット・出来ることを知る 4. 何故インターフェースを使うのか考える＆言語化してコードを書く を繰り返す 5. 和解（自分なりの意図を持ってインターフェースを使える状態） 皆さんがインターフェースを使う上で気をつけている事も 是非教えてください！！
26. Thank You! 26