ところで、なぜ重要なのか

Why Reactive Programming Matters.

えーと、リアクティブプログラミングがなぜ重要なのか、というのが本題でした。なので、実はここからがメインです。
なぜ重要だと思うのか書かなければいけません。その理由について、モジュール性の向上と状態管理の自動化という点から見てみたいと思います。

モジュール性は大事

関数プログラミングはなぜ重要か」によれば、
関数型プログラミングの利点は関数のモジュール性の高さによるものです。
そして関数のモジュール性の高さを遺憾なく発揮するために、副作用が無いことや遅延評価であることが必要なのだと。

リアクティブプログラミングも同じです。副作用を含むシステムをうまくモジュール化できる可能性があるから重要なのです。

構造化プログラミングからオブジェクト指向関数型プログラミングへの進化の歴史は、
モジュール性の向上の歴史でもあり、同時に「変更可能な状態」との戦いの歴史でもあります。

構造化プログラミングは、制御フローをモジュール化することに成功しましたが、
その後に「グローバル変数」の問題が残されました。
制御フローがモジュール化されてもデータがモジュール化されていなかったのです。

そこでオブジェクト指向は、データと手続きをまとめてモジュール化しました。
そこで残った問題は「変更可能なオブジェクト」のモジュール性は、実はそんなに高くないということです。
オブジェクト指向の問題は、状態をオブジェクトに閉じ込めても、各オブジェクトが持つ状態間の相互作用をゼロにすることはできないことです。
状態を持つシステムとやりとりを行うプロトコルの設計を考えればわかりやすいですが、相手が状態をもつ以上、それとやりとりする側も
相手の事情、つまり今どんな状態なのかをまったく無視して話しかけるということはできないのです。

一方純粋関数型プログラミングでは、副作用を排除した関数をモジュールとすることで、高いモジュール性を得ました。
しかしそんな純粋関数型プログラミングも外部とやりとりをして仕事をなすためには、
その強力な抽象化能力をもって手続き的な処理をシミュレートせざるを得ませんでした。

こう見ていくと、オブジェクト指向は副作用の分割統治を、関数型プログラミングは副作用の排除を行うことで、
モジュール性を高めようとしたと考えられます。
リアクティブプログラミングでは、値を直接扱うのではなく、
「時間とともに変化していく値=振る舞い」を扱うことで、関数型プログラミングのような宣言的な記述で
変化する状態をもつ系を記述できるのです。
変化する状態を扱いながらもモジュール性が落ちないのは、状態が変化したときにそれに依存した状態が自動的に更新されるため、
状態の依存関係について意識する必要がないからです。
オブジェクト指向では、状態に依存関係がある場合、まず初期値をセットするロジックを書き、さらにObserverパターンなどを用いて
更新を管理し、さらに効率的な更新のために適切なキャッシュポイントの設定まで明示的に行う必要があります。
リアクティブプログラミングでは、
更新の管理やキャッシュポイントの設定は自動的に行われるため、
プログラマの仕事は振る舞い間の関係性だけを宣言的な式で書くことだけになるのです。

自動化も大事

モジュール性の向上と並んで重要なのが、自動化による利点です。
これはGC(ガベージコレクション)とのアナロジーで考えると分かりやすいと思います。
GCは、メモリの管理を自動化してくれるため、メモリの確保・解放を明示的にする必要がなくなります。
これによってコードの記述量が減らせるのはもちろんですが、もっとも重要なのはメモリリークや無効なポインタに関するバグなどの、
メモリ管理にまつわるバグを削減できることです。
手作業によるメモリ管理は手間がかかるだけでなく、バグの温床にもなりかねないわけですが、一度メモリ管理を自動化する仕組みを作ってそれに任せてしまえば、
場当たり的に実装するよりもバグを減らすことが可能だという理屈です。

これと同じことがリアクティブプログラミングにもあてはまります。
Observerパターンによる状態の管理は、バグを生み出しやすいことで知られています。
状態の更新管理を手作業で一つ一つ指示していくため、メモリ管理と同じく、
抜け漏れがあると特定のパターンでのみ矛盾した状態を招く厄介なバグを生み出す可能性があります。
なので状態の変更を管理する仕組みを作ってそれに任せてしまえばよいというのがリアクティブプログラミングの考え方だともいえます。