Slide 1
Slide 1 text
実践、Interface
PHPカンファレンス関西2024
Slide 2
Slide 2 text
自己紹介
Slide 3
Slide 3 text
名前：おぎ
PHPer歴：4年目（自称にわか）
住んでるところ：秘境グンマー
所属：Innovator Japan.inc
特技：スノーボード
Slide 4
Slide 4 text
過去の発表等
Slide 5
Slide 5 text
Innovator Japan Inc.
日本発のビジネスデザインカンパニー
「人の可能性を最大限に引き出し、ウェルビーイングな社会を実現する
」
Slide 6
Slide 6 text
宣伝終わり
Slide 7
Slide 7 text
実践、Interface
PHPカンファレンス関西2024
Slide 8
Slide 8 text
今日の話
● Interfaceで何ができるの？
● Interfaceの何が嬉しいの？
● まとめ
Slide 9
Slide 9 text
Interfaceで何ができるの？
Slide 10
Slide 10 text
例：会員制のメディアサイト
よくある機能
- ログインの有無による表示の切り替え
- 会員ステータスに応じたコンテンツの出し分け
よくある追加要件
- 会員ステータスの種類を追加したい
サンプルコードの段階を追いながら考えてみましょう
Slide 11
Slide 11 text
①素朴な実装
Slide 12
Slide 12 text
テンプレート直書き！！
Slide 13
Slide 13 text
①素朴な実装の問題点
● Viewにロジックが漏れているので会員が増えるたびに無限に分岐
が入り組んでいく（つらい）
● 微妙に変数名やHTMLが変わっているとgrep検索でも引っかからな
いので修正漏れが発生する（つらい）
● テンプレートからどんな見た目になるのかが全く想像できない
（つらい）
Slide 14
Slide 14 text
②具象への依存
Slide 15
Slide 15 text
Bladeのコードが抽象化された！
Slide 16
Slide 16 text
Postモデル内は分岐
Slide 17
Slide 17 text
②具象への依存の問題点
● テストはできるようになった
● 会員を追加するのにUserモデル以外にPostモデルも修正が必要
（ウッ！）
● そして多分似たような感じで会員のステータスに依存している箇所をすべて直す羽
目になる
（つらい）
一つの変更に対して波及する箇所が多すぎる！🥺
Slide 18
Slide 18 text
③抽象への依存
Slide 19
Slide 19 text
③抽象への依存
Slide 20
Slide 20 text
③抽象への依存のメリット
抽象に依存することで使う側のコードがシンプルに
Slide 21
Slide 21 text
抽象に依存したことで
シンプルで拡張性の高いコードになった🎉
Slide 22
Slide 22 text
Interfaceの何が嬉しいのか？
Slide 23
Slide 23 text
抽象に依存したことで
シンプルで拡張性の高いコードになった🎉
Slide 24
Slide 24 text
というのは
結果の一つであって本質ではない
Slide 25
Slide 25 text
https://amzn.asia/d/9WkYDgp
OO（オブジェクト指向）とは「ポリモーフィズム
を使用することでシステムにあるすべてのソー
スコードの依存関係を絶対的に制御する能
力」である。
〜Robert C. Martin〜
Slide 26
Slide 26 text
No content
Slide 27
Slide 27 text
直接の依存がなくなった！
矢印の向きが逆転した！
Slide 28
Slide 28 text
Interfaceの効能
1. 薄いレイヤーが実装同士の間に生まれ、依存の向きが変わった
（依存関係逆転原則）
2. 抽象に依存するようになったことで、使う側のプログラムが安定した
（安定依存の原則）
3. 多彩なインスタンスを注入して拡張できるようになった
（多態性）
Slide 29
Slide 29 text
任意の方向へ依存を向けることで
何に依存して、何に依存しないかを
選ぶことができる
Slide 30
Slide 30 text
まとめ
Slide 31
Slide 31 text
Interfaceの話は「アーキテクチャ」の話
（ ≠ EASY）
Slide 32
Slide 32 text
Interfaceが不要なパターン
● 極端に小さいシステム
→ ２週間〜１ヶ月で書き直しできるようなシステム
● 複雑でないシステム
→ 処理の中身の意図まですぐに把握できるコードベース
● 短命・使い捨てのシステム
→ MVP等の場合は作り込むコストのほうが嵩む
Slide 33
Slide 33 text
Interfaceがあった方が良いパターン
● 複数開発者が必要になる規模のシステム
→ 複数開発者で認識や概念の齟齬が起きにくい
● 概念が複雑になりがちなシステム
→ 「接合部」を作ることで影響範囲を閉じることができる
● 長期間稼働する前提のシステム
→ 開発者が入れ替わった時も制約がガイドの役割を果たす
Slide 34
Slide 34 text
https://x.com/suthio_/status/1691972270208803260?s=20
Slide 35
Slide 35 text
つまり「チーム開発」の話
Slide 36
Slide 36 text
設計するアーキテクトだけでなく
プログラマも理解する必要がある
Slide 37
Slide 37 text
おすすめの発表／書籍
Slide 38
Slide 38 text
https://fortee.jp/phpcon-kansai2024/proposal/b3f6ed97-8551-4
0da-90b1-3a14697df303
Slide 39
Slide 39 text
https://fortee.jp/phpcon-kansai2024/proposal/0d9231ed-2f64-4
908-bd16-863922f56c0f
Slide 40
Slide 40 text
https://fortee.jp/oocon-2024/proposal/857fd0a4-b04e-41f1-a0f3-6bbeb3fa0779
Slide 41
Slide 41 text
https://amzn.asia/d/dj7nHWu https://amzn.asia/d/c0yxnFB
Slide 42
Slide 42 text
https://amzn.asia/d/cBgQx2Q https://amzn.asia/d/aDdKgzX https://amzn.asia/d/aDdKgzX
Slide 43
Slide 43 text
賢くInterfaceを使って
よりよい設計・開発をしていきましょう👍
Slide 44
Slide 44 text
ご清聴ありがとうございました🙇