設計、Interface

Interfaceの設計、していますか？

適切なInterface設計はコードの再利用性を高め、保守性を高める一方
不適切な設計をしてしまうと不要な複雑性を周辺に生み出し保守性に大きな悪影響を及ぼしてしまいます

Interfaceを設計するとはそもそもどういうことか？
良いインターフェースの条件
インターフェース設計の先にあるもの

といった切り口に対して

サンプルコード
有名な設計原則
書籍の引用

などを用いながら「良いInterface設計」とその効果について解説します

Transcript

1. 設計、Interface funabashi.dev
2. 自己紹介
3. 名前：おぎ PHPer歴：4年目（自称にわか） 住んでるところ：秘境グンマー 所属：某HRテック 特技：スノーボード
4. 過去の発表等
5. 本日のテーマ - 「Interfaceを設計する」とは？ - 「良いInterface」とは？ - Interfaceの設計とその先
6. 「Interfaceを設計する」 とは？
7. 言語機能としてのInterface インタフェース (英: interface) は、JavaやC#などのオブジェクト指 向プログラミング言語においてサポートされる、実装を持たない 抽象型のことである。 出典: フリー百科事典『ウィキペディア（ Wikipedia）』
8. 言語機能としてのInterfaceに関してはこちら https://speakerdeck.com/fuwasegu/object-oriented-conference-2024
9. 広義のインターフェース 情報技術において、インタフェース（英: interface）は、情報の授 受を行うシステム間のプロトコル、または、その接続を行う部分 をいう 出典: フリー百科事典『ウィキペディア（ Wikipedia）』 今回扱うのはこっち寄り！ （関数、メソッド）
10. API
11. Application Programming Interface
12. API Application ＝ プログラムやシステム Programming Interface ＝プログラミング対象となるインターフェース
13. 設計
14. 設計とは？ 広義には社会的な機構・組織・制度、機械・器具などを組み合 わせて、特定の目的を達成するためのシステムを作り上げる 知的作業を指す 出典: フリー百科事典『ウィキペディア（ Wikipedia）』
15. 本発表におけるInterfaceの設計 （プログラムやシステムの） ≒シグネチャ（入出力ルール）を決 めること
16. 「良いInterface」とは？
17. 良いインターフェースの条件 - 疎結合・高凝集 - SOLID原則 - UNIX哲学 - SLAP原則 - QUPID原則 - etc, etc…
18. 全網羅は無理！
19. なので今日は３つだけ 紹介します
20. 良いインターフェースの条件①： 理解容易性
21. 理解容易性
22. 理解容易性 リーダブルコード：“コードは理解しやすくなければいけない” UNIX哲学：“一つのことをうまくやる” プリンシプルオブプログラミング：“コードは必ず変更される” ものづくりは基本的に作る時間より使う時間の方が長い ので、 「扱う人」のことを考えて設計する必要がある
23. 条件①：使い手が理解しやすい
24. 良いインターフェースの条件②： テスト容易性
25. テスト容易性 問題：次の関数をテストするには何をどうしたら良いでしょう？
26. テスト容易性 - $countryって国名？国コード？ - $datatypeってそもそも何？値は何が入るの？ - $yearって文字列？数字？というかなんの指定？？ - そもそもこの関数実行すると何が起きるの？ 何もわからない...😇 （コード読むしかない）
27. テスト容易性 https://www.php.net/manual/ja/language.types.mixed.php ちなみに...
28. テスト容易性 https://speakerdeck.com/uzulla/throw-away-all-php-array-now
29. テスト容易性 問題：次の関数をテストするにはどうしたら良いでしょう？ A：無限の可能性があるのでテストしきれない
30. テスト容易性 問題：次の関数をテストするにはどうしたら良いでしょう？
31. https://speakerdeck.com/shin1x1/restricting-states
32. 条件②：使い手が検査しやすい
33. 良いインターフェースの条件③： 拡張性
34. 拡張性 - 実装に対してプログラミングをする →実装が変更されると使っている側も容易に壊れる - 抽象化されたインターフェースに対してプログラミングをする →インターフェース（入出力）が変更されない限りは壊れない 例：インターフェースを変更することなくクラスを新しく追加するだけで振る 舞いを拡張できる
35. 拡張性 15分では到底おさまらないので ↓を見てください＞＜；
36. 条件③：作り手が拡張しやすい
37. まとめ
38. 良いインターフェースは... - 理解がしやすい！ - 検査がしやすい！ - 拡張しやすい！ でもそれって作る人が大変じゃん ...？
39. Q.なぜ良いインターフェースの設計が必要か？
40. A.持続可能な開発 のため
41. ソフトウェアは意外と長生きする、ソフトウェアは必ず変更される その変更を行うのがあなたとは限らない ... だからこそ 作るプロとして理解しやすく、拡張しやすい設計をし、 将来の同僚たちが素早く価値を届けられるように、 無為なデバッグや調査に時間を費やすことなく仕事を終えられるように、 設計を通して心遣いを未来に送りたい
42. 良い設計 ≒ より良い未来の設計 ≒ 未来の自分たちへの思いやり
43. ご清聴ありがとうございました
44. Appendix：参考資料 - リーダブルコード - UNIXという考え方 - プリンシプルオブプログラミング - Monologの実装に学ぶInterfaceの使い所 - Interfaceの目的別分類 - PHPの最高機能、配列を捨てよう！ - 制約の力 -状態を限定する- - ちょうぜつソフトウェア設計入門 - Clean Craftsmanship