はじめに
こんにちは。Streamerioアドベントカレンダー9日目から担当する guu です。
Streamerioでは、主にゲーム側のUIを担当していました。
これまで、ゆうだいさんが Web側とバックエンド側のこだわりを詳しく書いてくれています。
今日からはバトンを受け取って、ゲーム側の実装でこだわった点 を紹介していきます。
今回から4回にわたって Unity の DI 設計について書いていきます。
第1回となる今回は「DI導入編」です。
Streamerio の概要は、まず 1日目の記事をご覧ください。
DIとは
DI（Dependency Injection）は、クラスが必要とする依存オブジェクトを自分で生成せず、外部から受け取るという設計思想です。
これにより、クラスを違うものに変えたい時、渡すクラスを差し替えるだけでよくなり、変更に強くなります。
今回は、クラスを渡す部分を自動化してくれるDIコンテナを使用しました。
DI導入のきっかけ
DIってなんかかっこいいですよね。
……という本音はさておき。
Web側やバックエンド側が設計にこだわり始めたのを見て、ゲーム側もちゃんと設計を詰めたいという話があがりました。
じゃあ具体的にどこをこだわろうかと考えたときに、まず 機能の中身を気にせず、窓口となるクラスだけで使える構成 にしたいと思いました。
さらに、MonoBehaviour 依存を減らして軽量で扱いやすい実装 にしたい、という狙いもありました。
この2つをやりたくてDIを導入しました。
VContainer導入理由
UnityでDIを導入するにあたって、まずはコンテナ選びが必要になります。
代表的なものは、ExtenjectとVContainerの2つです。
今回は、動作が軽く、簡単に使えそうという理由でVContainerを採用しました。
おわりに
今回は、DIについてと、ゲーム側でDIを導入した理由を紹介しました。
次回からは、VContainerを使って実際にどう設計・実装していったかを説明していきます。
第2回のテーマは 「代表クラスだけを別コンテナに公開する」 です。
最後まで読んでくれてありがとうございます！次回もゆるっと見てもらえるとうれしいです‼︎