Rxをオブジェクト中でどう使うか？

今までのオブジェクト指向の書き方と変わらないと思う

SOLID原則がRxで変わることはない。むしろSOLID原則に従い、このクラスの責務は何なのか？という点を意識したら書きやすくなると思う

オブジェクトの外にはRxの何を公開すべきか？

Observable! TypeScriptならばObservableインターフェイスが定義されている。.NETならばIObservableインターフェイスを公開する。JavaはObservabeオブジェクトを公開する

ドメインロジックに従い(何かのストリームを公開するという責務がそのクラスにあるはず！)、ストリームを作成し、その作成したストリームを公開するべし

.NETのeventの使い方は参考になると思う。あれは元々callback++として開発され、Rx導入したらそのままIObservableに置き換えられる言語機能である。

クラス内に状態マシンをなるべく作らないようにしよう

Rxのオペレータは強力だから、状態マシンは基本要らないハズである

Doを使って副作用を起こしていたり、Subjectを多用して複雑になっていたら、オペレータをちゃんと使えてないか、何かを間違えている

Observable VS Task/Future

Task/Futureは単一の値を返す非同期処理に使う物であり、Observableは複数の値を返し、編集可能なイベントストリームである。よって用途が微妙に違う

.NET/Javaは相互変換可能なので、どちらを使うべきかを考慮して使うのが良いと思う。(戻り値としてはFutureだが、内部ではObservableを使う等)

C#にはasync/awaitがあるし、次期C++/JSにもasync/await構文が入る噂があるから、言語の状況に応じて上手く使いましょう。

(今のところ自分が考える)理想的なRxの使い方

• 実装するクラスの責務に従いつつ、コンストラクタでRxのストリームを組み立ててしまう
• ストリームの結果を公開する必要があれば、Observableとして公開する
• 他のクラスのストリームを参照したければ、コンストラクタ引数で要求する。コンストラクタ引数の解決は適切なDIコンテナを使用する
• ストリームの操作は基本的にオペレータを使用する。
• オペレータで出来ないストリーム操作が必要になったらオペレータを自作する。
• Doは基本デバッグ用途で、悪手。コードを見なおしたほうが良い