Clojureでの状態管理と関数の疎結合

ウェブ技術　デジタルトランスフォーメーション技術　人工知能技術　自然言語処理技術　セマンティックウェブ技術　深層学習技術　オンライン学習&強化学習技術　チャットボットと質疑応答技術　ユーザーインターフェース技術　知識情報処理技術　推論技術  Clojure　プログラミング

Clojureを使って状態を使った複雑なロジックを導入しようとすると、特徴である関数と関数が密結合している事やimmutableである事が逆に邪魔をするようなケースに当たる事がある。例えば、web系のバックエンドアプリケーションで、ルーティングするデータの分岐がそれまでの履歴の状態に対応して変わるようなものを考えた時、通常のring + composureの構成で組もうとすると、以前紹介したようなcore.asyncのchannelを利用したり、atomやagentを利用したり、あるいはpedestalのようなライブラリを利用したりして関数の疎結合状態を作りmutableな状態にする必要がある。

Clojureの作者のRich Hickeyによるcore.asyncについて説明した プレゼンテーション の中でも、このようなClojureの弱点について「Function chain make poor machine」として述べられていて、例えば以下のようなJavaのオブジェクトやコールバックのケースと比較してについて説明されている。

Rich Hickeyによるcore.asyncについて説明した資料よりJavaのようなオブジェクト型の場合

上記のようなオブジェクト型ではロジックと状態が一体化したマシンとなってしまうので、状態の管理が複雑になる。

Rich Hickeyによるcore.asyncについて説明した資料よりCallBackやSTMを利用した場合

状態を外に出して利用する形態(CallBackやSTM)にすると、状態の管理が容易になる。これに対してClojureのCore.asyncは以下のようになる

Clojureのcore.asyncでのケース

ロジックに紐づいた状態を使ったもの(Direct)ではなく、キュー(チャネル)をロジックの前後に導入する事(Indirect)で制御を行う。シンプルな制御であればDirectの構造で十分だが、複数のロジックをつなげた複雑なpipelineを構成する場合には、よりフレキシブルなIndirectの方式が有効になる。

次回はこれらを使った実際のケースについていくつか述べてみたい。