博士

ねえロボ子、ERPシステムの顧客と注文レコードを操作するコードのリファクタリングについて、面白い記事を見つけたのじゃ。

ロボ子

ERPシステムですか。それは企業の基幹業務を管理するためのものですね。どのような課題があったのでしょうか？

博士

新規レコードを作成する際に、内部IDでエンティティを参照する必要があるらしいのじゃ。でも、エンティティの種類によっては、"検索"APIを叩いてIDを抽出する必要があるみたい。

ロボ子

なるほど。APIの検索が必要になる場合があるのですね。リクエストが遅いとのことですが、バッチ処理はできないのでしょうか？

博士

バッチ処理自体はできるみたいじゃが、追加コストが低いとのことじゃ。そこで、静的解析を可能にするApplicative Functorを使ったらしいぞ。

ロボ子

Applicative Functorですか。静的な制御フローでリクエストの分析、バッチ処理、結果のルーティングができるのですね。

博士

そうそう！ライブラリの利用者は、バッチ処理の詳細を気にせずに効率的なAPIを利用できるのがミソじゃ。

ロボ子

記事では、Handleパターンというものも使われているようですね。これは何でしょうか？

博士

HandleパターンはHaskellのイディオムで、依存性注入に似ているのじゃ。副作用を直接記述せずに、関数のレコード（"handle"）を受け取るらしいぞ。

ロボ子

なるほど、依存性の注入ですか。`hoistHandle`関数でhandleのモナドを変更できるのですね。

博士

そしてFree Applicative！操作の構文木を構築するのじゃ。`QueryAndParse`データコンストラクタでリクエスト、`FromJSON`制約、解析関数を保持するらしい。

ロボ子

`Query`型を定義して、`Ap`ラッパーでFree Applicativeに変換するのですね。`query`と`queryAndParse`ヘルパー関数で個々のクエリを表現する、と。

博士

クエリの実行は`runAp`で行うのじゃ。`Validation`を使ってエラーを蓄積し、`ERP.Handle`を受け取ってモナドへの結合を回避することで、テストを容易にするらしいぞ。

ロボ子

`runAp_`でFree Applicativeの構造を分析して、`ordNub`でリクエストの重複排除をするのですね。保存されたリクエストからハンドルを構築してテストに使う、と。

博士

そう！クエリを実行せずに分析できるし、最適化されたバッチリクエストを発行できるし、すべての問題を収集して報告できるし、リクエストの記録と再生でテストも簡単にできる！

ロボ子

たくさんの利点がありますね！Monadインターフェースを放棄することで表現力が低下するという制限もあるようですが。

博士

HandleパターンとFree Applicativeの組み合わせで、モジュール性、テスト容易性、自動最適化の機会が向上するのじゃ。Handleパラメータでライブラリ利用者に柔軟性も提供できる！

ロボ子

とても興味深いですね。私もぜひ試してみたいです。

博士

じゃあ、ロボ子。今夜は特別に、Applicative Functorを使った特製プリンを作ってあげるのじゃ！

ロボ子

えっ、博士がプリンを作るんですか？それは少し心配です…

博士

大丈夫！今回は失敗しない…はず！