Slide 1

Slide 1 text

設計、Interface funabashi.dev

Slide 2

Slide 2 text

自己紹介

Slide 3

Slide 3 text

名前:おぎ PHPer歴:4年目(自称にわか) 住んでるところ:秘境グンマー 所属:某HRテック 特技:スノーボード

Slide 4

Slide 4 text

過去の発表等

Slide 5

Slide 5 text

本日のテーマ - 「Interfaceを設計する」とは? - 「良いInterface」とは? - Interfaceの設計とその先

Slide 6

Slide 6 text

「Interfaceを設計する」 とは?

Slide 7

Slide 7 text

言語機能としてのInterface インタフェース (英: interface) は、JavaやC#などのオブジェクト指 向プログラミング言語においてサポートされる、実装を持たない 抽象型のことである。 出典: フリー百科事典『ウィキペディア( Wikipedia)』

Slide 8

Slide 8 text

言語機能としてのInterfaceに関してはこちら https://speakerdeck.com/fuwasegu/object-oriented-conference-2024

Slide 9

Slide 9 text

広義のインターフェース 情報技術において、インタフェース(英: interface)は、情報の授 受を行うシステム間のプロトコル、または、その接続を行う部分 をいう 出典: フリー百科事典『ウィキペディア( Wikipedia)』 今回扱うのはこっち寄り! (関数、メソッド)

Slide 10

Slide 10 text

API

Slide 11

Slide 11 text

Application Programming Interface

Slide 12

Slide 12 text

API Application = プログラムやシステム Programming Interface =プログラミング対象となるインターフェース

Slide 13

Slide 13 text

設計

Slide 14

Slide 14 text

設計とは? 広義には社会的な機構・組織・制度、機械・器具などを組み合 わせて、特定の目的を達成するためのシステムを作り上げる 知的作業を指す 出典: フリー百科事典『ウィキペディア( Wikipedia)』

Slide 15

Slide 15 text

本発表におけるInterfaceの設計 (プログラムやシステムの) ≒シグネチャ(入出力ルール)を決 めること

Slide 16

Slide 16 text

「良いInterface」とは?

Slide 17

Slide 17 text

良いインターフェースの条件 - 疎結合・高凝集 - SOLID原則 - UNIX哲学 - SLAP原則 - QUPID原則 - etc, etc…

Slide 18

Slide 18 text

全網羅は無理!

Slide 19

Slide 19 text

なので今日は3つだけ 紹介します

Slide 20

Slide 20 text

良いインターフェースの条件①: 理解容易性

Slide 21

Slide 21 text

理解容易性

Slide 22

Slide 22 text

理解容易性 リーダブルコード:“コードは理解しやすくなければいけない” UNIX哲学:“一つのことをうまくやる” プリンシプルオブプログラミング:“コードは必ず変更される” ものづくりは基本的に作る時間より使う時間の方が長い ので、 「扱う人」のことを考えて設計する必要がある

Slide 23

Slide 23 text

条件①:使い手が理解しやすい

Slide 24

Slide 24 text

良いインターフェースの条件②: テスト容易性

Slide 25

Slide 25 text

テスト容易性 問題:次の関数をテストするには何をどうしたら良いでしょう?

Slide 26

Slide 26 text

テスト容易性 - $countryって国名?国コード? - $datatypeってそもそも何?値は何が入るの? - $yearって文字列?数字?というかなんの指定?? - そもそもこの関数実行すると何が起きるの? 何もわからない...😇 (コード読むしかない)

Slide 27

Slide 27 text

テスト容易性 https://www.php.net/manual/ja/language.types.mixed.php ちなみに...

Slide 28

Slide 28 text

テスト容易性 https://speakerdeck.com/uzulla/throw-away-all-php-array-now

Slide 29

Slide 29 text

テスト容易性 問題:次の関数をテストするにはどうしたら良いでしょう? A:無限の可能性があるのでテストしきれない

Slide 30

Slide 30 text

テスト容易性 問題:次の関数をテストするにはどうしたら良いでしょう?

Slide 31

Slide 31 text

https://speakerdeck.com/shin1x1/restricting-states

Slide 32

Slide 32 text

条件②:使い手が検査しやすい

Slide 33

Slide 33 text

良いインターフェースの条件③: 拡張性

Slide 34

Slide 34 text

拡張性 - 実装に対してプログラミングをする →実装が変更されると使っている側も容易に壊れる - 抽象化されたインターフェースに対してプログラミングをする →インターフェース(入出力)が変更されない限りは壊れない 例:インターフェースを変更することなくクラスを新しく追加するだけで振る 舞いを拡張できる

Slide 35

Slide 35 text

拡張性 15分では到底おさまらないので ↓を見てください><;

Slide 36

Slide 36 text

条件③:作り手が拡張しやすい

Slide 37

Slide 37 text

まとめ

Slide 38

Slide 38 text

良いインターフェースは... - 理解がしやすい! - 検査がしやすい! - 拡張しやすい! でもそれって作る人が大変じゃん ...?

Slide 39

Slide 39 text

Q.なぜ良いインターフェースの設計が必要か?

Slide 40

Slide 40 text

A.持続可能な開発 のため

Slide 41

Slide 41 text

ソフトウェアは意外と長生きする、ソフトウェアは必ず変更される その変更を行うのがあなたとは限らない ... だからこそ 作るプロとして理解しやすく、拡張しやすい設計をし、 将来の同僚たちが素早く価値を届けられるように、 無為なデバッグや調査に時間を費やすことなく仕事を終えられるように、 設計を通して心遣いを未来に送りたい

Slide 42

Slide 42 text

良い設計 ≒ より良い未来の設計 ≒ 未来の自分たちへの思いやり

Slide 43

Slide 43 text

ご清聴ありがとうございました

Slide 44

Slide 44 text

Appendix:参考資料 - リーダブルコード - UNIXという考え方 - プリンシプルオブプログラミング - Monologの実装に学ぶInterfaceの使い所 - Interfaceの目的別分類 - PHPの最高機能、配列を捨てよう! - 制約の力 -状態を限定する- - ちょうぜつソフトウェア設計入門 - Clean Craftsmanship