設計の考え方 インターフェースと腐敗防止層編 2024/06/22 PHP カンファレンス福岡 2024

所属：株式会社ウィルゲート 登壇： 寄稿： 岡田 正平／おかしょい X: @okashoi GitHub: @okashoi

本セッションは以下を満たす人を想定聴講者としています • PHP のコードは一通り書ける（フレームワーク上でも可） • 機能追加等によって、実装上の設計を考える必要がある （考えたことがある） • クラスベースのオブジェクト指向プログラミングにおける 「継承」等の挙動はわかる おことわり

「腐敗防止層」という考え方 • 原典から簡略化して、コンセプトだけ説明 • システムを長生きさせるために意識したいこと このセッションで伝えること 出典： Eric Evans.『エリック・エヴァンスのドメイン駆動設計』(p.376). 翔泳社. Kindle 版.

• ライブラリを使うときに何を考慮するか • PHP であれば Composer、JavaScript であれば npm など でインストールするもの 考えてみよう

php-ulid というライブラリを使ったコード • ULID とは全世界で一意かつソート可能な識別子 • 注：php-ulid であることに特に意味はない （ライブラリを使ったコードなら何でもよかった） https://github.com/robinvdvleuten/php-ulid 課題設定 1

① そのまま php-ulid を使った例

② 1 枚薄い wrapper を噛ませた例

② 1 枚薄い wrapper を噛ませた例

② 1 枚薄い wrapper を噛ませた例

② 1 枚薄い wrapper を噛ませた例

どうしてわざわざそんなことを......？

そのまま使った例（ケース①）の現状 php-ulid User uses

User 以外にも ULID で採番していくとこう php-ulid User uses Post Comment …… uses uses uses

「そのとき」はやってくる • ライブラリのバージョンアップ • ライブラリに深刻な不具合が見つかった • ライブラリがメンテナンスされなくなった • 別のライブラリの方が性能が良いことが分かった ......etc. そしてある日...... ※あくまで例えなので php-ulid がそれに該当するという話ではない

影響範囲は利用箇所すべてに及ぶ php-ulid User uses Post Comment …… uses uses uses

影響範囲は利用箇所すべてに及ぶ php-ulid User uses Post Comment …… uses uses uses

wrapper を噛ませていた場合（ケース②） MyUlid User uses php-ulid uses

同様に増えていっても MyUlid User uses php-ulid uses Post Comment …… uses uses uses

同様に増えていっても MyUlid User uses php-ulid uses Post Comment …… uses uses uses

影響は wrapper までに留められる（※） MyUlid User uses php-ulid uses Post Comment …… uses uses uses ※ただし wrapper のインターフェース　 が変わらない前提

ライブラリに限らず、以下についても当てはまる • フレームワークの機能 • データベースとのやりとり • 外部システムとのやりとり（Web API 等経由） この役割が「腐敗防止層」

影響は wrapper までに留められる（※） MyUlid User uses php-ulid uses Post Comment …… uses uses uses ※ただし wrapper のインターフェース　 が変わらない前提

影響は wrapper までに留められる（※） MyUlid User uses php-ulid uses Post Comment …… uses uses uses ※ただし wrapper のインターフェース　 が変わらない前提

ここで言う「インターフェース」には 2 つの意味がある 広義のインターフェース = API（Application Programming Interface） 狭義のインターフェース = プログラミング言語の機能として提供される抽象型 「インターフェース」とは

API（Application Programming Interface） • 関数であれば引数と戻り値など • 作り手と使い手の間の「決めごと」 • 「仕様」と言い換えてもよい 広義のインターフェース

プログラミング言語の機能として提供される抽象型 狭義のインターフェース

設計における重要な判断 以下のようなインターフェースは避けたい • 依存ライブラリの変更が、利用する側にも影響してしまう • 実装の詳細を知らないと正しく使えない （広義の）インターフェースをどう定めるか？

所定の形式で HTTP リクエストを行う処理がある • 実際の HTTP リクエスト部分には Guzzle を用いる • wrapper を噛ませて利用者は Guzzle を意識しないよ うにしたい https://github.com/guzzle/guzzle 課題設定 2

GuzzleHttp\ClientTrait /** * Create and send an HTTP GET request. * * Use an absolute path to override the base path of the client, or a * relative path to append to the base path of the client. The URL can * contain the query string as well. * * @param string|UriInterface $uri URI object or string. * @param array $options Request options to apply. * * @throws GuzzleException */ public function get($uri, array $options = []): ResponseInterface { return $this->request('GET', $uri, $options); }

• 第三者が定める標準を利用できないか検討する • 自分たちで設計する場合は対象を「抽象化」する • 利用する側が、内部実装や依存ライブラリの詳細を 意識しなくても良いようにする • 公開する操作を使うものだけに絞る （広義の）インターフェースをどう定めるか？

• 第三者が定める標準を利用できないか検討する • 自分たちで設計する場合は対象を「抽象化」する • 利用する側が、内部実装や依存ライブラリの詳細を 意識しなくても良いようにする • 公開する操作を使うものだけに絞る （広義の）インターフェースをどう定めるか？

GuzzleHttp\ClientTrait /** * Create and send an HTTP GET request. * * Use an absolute path to override the base path of the client, or a * relative path to append to the base path of the client. The URL can * contain the query string as well. * * @param string|UriInterface $uri URI object or string. * @param array $options Request options to apply. * * @throws GuzzleException */ public function get($uri, array $options = []): ResponseInterface { return $this->request('GET', $uri, $options); } URI の文字列か、PSR に則っているので ここはそのまま使うという選択肢は充分ありえる

PHP-FIG という組織が定める「標準勧告」 • オートローディングに関する仕様（PSR-4） • コーディングスタイル（PSR-1、PSR-12） • インターフェース（上記以外） あくまで第三者組織による「勧告」であり、強制力を 持つものではない 補足：PSR（PHP Standards Recommendations）

補足：PSR（PHP Standards Recommendations） https://www.php-fig.org/psr/

• 第三者が定める標準を利用できないか検討する • 自分たちで設計する場合は対象を「抽象化」する • 利用する側が、内部実装や依存ライブラリの詳細を 意識しなくても良いようにする • 公開する操作を使うものだけに絞る インターフェースをどのように定めるか？

GuzzleHttp\ClientTrait /** * Create and send an HTTP GET request. * * Use an absolute path to override the base path of the client, or a * relative path to append to the base path of the client. The URL can * contain the query string as well. * * @param string|UriInterface $uri URI object or string. * @param array $options Request options to apply. * * @throws GuzzleException */ public function get($uri, array $options = []): ResponseInterface { return $this->request('GET', $uri, $options); }

このような wrapper を噛ませても get($url); return $response->getBody()->getContents(); } }

実際に使おうとすると client->get($url); } catch (GuzzleException) { // なんらかのエラー処理 } // 後続処理 } }

まだ GuzzleHttp へ直接依存してしまっている client->get($url); } catch (GuzzleException) { // なんらかのエラー処理 } // 後続処理 } }

GuzzleHttp\ClientTrait /** * Create and send an HTTP GET request. * * Use an absolute path to override the base path of the client, or a * relative path to append to the base path of the client. The URL can * contain the query string as well. * * @param string|UriInterface $uri URI object or string. * @param array $options Request options to apply. * * @throws GuzzleException */ public function get($uri, array $options = []): ResponseInterface { return $this->request('GET', $uri, $options); } GuzzleHttp 固有の例外なので 腐敗防止層では適切にハンドリングして • PHP 組み込みの例外に変換 • 独自定義の例外に変換 • 正常系として適切に処理 等の対応をしておきたい

• 第三者が定める標準を利用できないか検討する • 自分たちで設計する場合は対象を「抽象化」する • 利用する側が、内部実装や依存ライブラリの詳細を 意識しなくても良いようにする • 公開する操作を使うものだけに絞る インターフェースをどのように定めるか？

GuzzleHttp\ClientTrait /** * Create and send an HTTP GET request. * * Use an absolute path to override the base path of the client, or a * relative path to append to the base path of the client. The URL can * contain the query string as well. * * @param string|UriInterface $uri URI object or string. * @param array $options Request options to apply. * * @throws GuzzleException */ public function get($uri, array $options = []): ResponseInterface { return $this->request('GET', $uri, $options); }

GuzzleHttp\ClientTrait /** * Create and send an HTTP GET request. * * Use an absolute path to override the base path of the client, or a * relative path to append to the base path of the client. The URL can * contain the query string as well. * * @param string|UriInterface $uri URI object or string. * @param array $options Request options to apply. * * @throws GuzzleException */ public function get($uri, array $options = []): ResponseInterface { return $this->request('GET', $uri, $options); } 確かに型情報としてはGuzzleHttpに依存していないが......

実態はライブラリ詳細 → wrapper を噛ませる場合は 　ユースケースにあわせて 　隠蔽しておきたいもの

• 第三者が定める標準を利用できないか検討する • 自分たちで設計する場合は対象を「抽象化」する • 利用する側が、内部実装や依存ライブラリの詳細を 意識しなくても良いようにする • 公開する操作を使うものだけに絞る インターフェースをどのように定めるか？

• 依存関係を逆転させられる • 具象（実装）を動的に切り替えられる • 継承とは別の切り口で多態性を実現できる ※単に「腐敗防止層」を実現するだけであれば必ずしも　 使う必要はない （狭義の）インターフェースを使う利点

• 依存関係を逆転させられる • 具象（実装）を動的に切り替えられる • 継承とは別の切り口で多態性を実現できる ※単に「腐敗防止層」を実現するだけであれば必ずしも　 使う必要はない （狭義の）インターフェースを使う利点

Laravel の config/session.php 具象（実装）を動的に切り替えられる https://github.com/laravel/framework/blob/02a0b5f6f83b13ea750f959364aefa324441a 354/config/session.php

具象（実装）を動的に切り替えられる https://www.php.net/SessionHandlerInterface

我々はこの端子の形を見て USB（Type-A）だと認識する 身近な抽象化、インターフェース

充電をするために両端の電気的特性を調べる必要はない → 利用者に詳細を意識させていないつくり 身近な抽象化、インターフェース

裏にある詳細を隠蔽する仕組み • HTTP • TCP/IP • VM • コンパイラ • ......etc. 利用者が専門知識を持たずとも便利に暮らせるのは インターフェースが適切に設計されているから 身近な抽象化、インターフェース

「腐敗防止層」という考え方 • 原典から簡略化して、コンセプトだけ説明 • システムを長生きさせるために意識したいこと このセッションで伝えること（再掲） 出典： Eric Evans.『エリック・エヴァンスのドメイン駆動設計』(p.376). 翔泳社. Kindle 版.