UniRx(リアクティブプログラミング)やZenject(DI)などをゲームに導入するのはどうなのかという考察

個人的にWebとかUIのような分野では別に使えばいいんじゃない？と思っているけど
ゲームに導入するのは懐疑的である。

密結合、疎結合という観点で捉えると

愚直な手続き

愚直に手続き型で書くというのが最も密結合と思われる。
密結合の利点はそこに全ての手順や、関連するものがあるという事であり
見ればだいたいわかるということである。

密なのだから、関連するモノが良く見えるし、あとだいたい速い。
その代わり密なので、それぞれが影響を受けやすい。

クラスを使う

クラスを用いて、関心毎でクラスをわけ、メッセージのやり取りで機能を実装するなどすると
少し疎結合になっていく。
しかしクラス間の依存などはあるし、蜜な部分も残る。
ただちゃんと設計すれば大規模なものであってもさほど困る事はない。

オブジェクト指向をちゃんと使っていればはっきり言ってさほど問題がない。
オブジェクト指向に振り回される人が問題。

インターフェースによる依存の逆転

インターフェースを使う事でクラスではなくインターフェースに依存するようになる。
このクラスがないと成り立ちませんではなく、インターフェースさえ決まってればよくなる。
また少し疎結合になった。

ただインターフェースだけだとそのクラスを誰がnewするのかとかあるし
newする奴はクラスそのものを知っていないといけないのでまだ密な部分は残る。

ただ疎結合になるということは、それだけ他とのつながりが見えなくなるという事でもある。
これは良い面もあるし悪い面もある。

シンプルに処理を追いづらくなってくるのだ。
メソッドの定義に飛んでみたらインターフェースかーいっっていう事が増えるし
実態はなんなんだよぉーという煩わしさも増えていく。

しかしここに関しては最悪実行時のデバッグ機能で呼び出し履歴とかあるし
そういう補助的なツールを合わせる事でさほど問題にはならない。
逆にデバッグ機能がお粗末だと、下手するとめっちゃしんどいのではないかと思う。

DIやリアクティブプログラミング

クラスをnewする部分を他の誰か、プログラミング外に任せてしまえれば
クラスはインターフェースに依存するだけでもよくなる。
いつ誰が作ったのかはしらないが、欲しい機能を備えたモノが与えられるのなら
クラス的にはそれで問題がないのだ。
疎結合である。

さらにプログラムで密になるシーンといえばオブジェクト間のやり取りや
他オブジェクトの参照である。

これをリアクティブにする事で一方は依存するが、一方は疎結合になっていく。
しかしこれの辛みはデバッグである。

疎結合すぎると、いったい、いつ、だれが、なんのために、この処理を実行するのか
ということまでも見えなくなってしまう。

そもそも疎結合にする事でユニットテストが可能になるなど
ただの機能の集まりになっていき、それらが何の意味を持つか、なんの意味を成すか
という部分は失われていくのである。

これ、ゲームでやるとめっちゃしんどいと思うんですよね。
まずオブジェクトの生成順や処理の実行順序は厳密に管理したいという場面も少なくないし
いくらパソコンの性能がよくなったからといっても
世の中のスマホやゲーム機というのはそこまでスペックも高くないのだ。

疎結合てユニットテストにこだわった結果、処理速度が出ない、メモリが不足して落ちる
というケースに陥いる例が後を絶たない。

しかもオブジェクト指向もまともに出来ない人が
DIやリアクティブをやるというのだから、まずまともに使えていないと思う。

そういう人はそもそもそういうバグを作る事はできても修正する事ができない
なのでちゃんとわかってる人にだけ面倒なタスクが降り注ぐ

その間にまた同じような問題を含むコードを量産されるのだからたまったもんじゃない。

そして、だいたい正しい使い方を学ぼうという話になるのだが
その状態で後から問題に気づいたとしても
そこまで来てからだと遅い。手遅れである。

あと使い方を学んでも仕方がない。
使うために必要な前提知識を学ばなければ使えるようにはならない。

と後半は愚痴みたいになったけど、ようするにゲームというジャンルにおいて
疎結合というのは必ずしも良いとは思えないのです。

interfaceを使ってちゃんとした設計をするあたりまでが程よい塩梅だと思っている。
リアクティブが許されるのはせいぜい、UIくらいではないだろうか
後は非同期ですかね。

非同期も非同期を使る理由が明確な所以外では使うべきではないと思っている。
楽にかける、便利という理由で使うモノではないと思う。