Extenject(Zenject)で同じコンポーネントをアタッチした複数のGameObjectを管理する話
なんの記事？
UnityにおけるDIの導入記事です。
同じコンポーネントをアタッチした複数のGameObjectを管理する方法を紹介します。
DIを導入してよかったこと、
UnityとDIを組み合わせて使うための工夫をまとめています。
※Extenject(ZenJect)を使用しています。
想定している読者
・DIってちょっと気になってるけど何がいいの？ という方
DIって結局何が良いの？
DIで解消したかったこと
プロジェクトが大きくなるにつれてクラスの置き場所に悩む時間が増えました。
参照の取り方が複雑になり、手軽に機能を実装できなくなってしまいました。
開発のフットワークを軽くするために抽象依存を達成したくなりました。
そのためにDIを利用しています。こう書くとシンプルですね。
プロジェクトの状況
ビフォーアフターを整理するために
現行プロジェクトの中を覗いてみましょう。
Singletonクラスを頂点とした参照が樹形図のように細分化されています。
▼イメージ
ここに考えなしに新しいクラスを作ると、
さらに細分化が進んでしまいます。
また、他のクラスでデータが必要になったときに参照を取りづらくなります。
いつかどこかで枝の先と先が依存しあうと
後の禍根は計り知れません。。。
これらの問題を予防できるクラスの正しい置き場所がわからない、、、
この苦悩が悩む時間を増やしていたのです…！
突如現れた希望の光 抽象依存
検索に検索を重ね、ついに希望の光を見出しました。
抽象依存です！
※指針となったコーディングに関する講演を置いておきます。自動翻訳でも十分わかると思います。
私はこれ幸いと設計のイメージを膨らませました！
これで勝つる！！
なんでできないの？
さあイメージはできた！いざ参る抽象依存！
意気揚々とＰＣに向きました。しかし、まだ無理でした。。。
参照の取り方そのものに問題があったのです。
現状はシングルトンクラスを頂点として、
Inspecter上のアタッチで参照を作ってありました。
そもそもUnityはInterfaceのアタッチ機能が弱いですし、
なんとかできたとしても、
一つのクラスに実装したInterfaceを、大量にアタッチしなければなりません。
これは無理だ。。。
やっとDIの話
そこでDIです！
単機能に分割したInterfaceを、
適切な場所に注入してくれます！
これで勝つる！！
同じコンポーネントをアタッチした複数のGameObjectを管理する話
記事内容移行のお知らせ
※2023/01/16
この項目の内容は、別記事にまとめ直しました
こちらをご参照ください。
まとめ
これでこの記事はおしまいです。
お読みいただいてありがとうございました。
DIパターンは画期的なパターンだと思いますが、
良くも悪くもチームの全員に特定の実装方法を強制するものになります。
また、Singleton×Unityの組み合わせは視覚的にも非常にわかりやすく、
プロジェクトの性質によってはまだまだ現役だと思います。
ご自身のプロジェクトにDIパターンが合いそうか、
考える一助になれましたら幸いです。
※2023/01/16
別記事に後半の内容をまとめ直し、移行しました。
謝辞
以下サイトさまから素材をお借りしました。
ヒューマンピクトグラム2.0 ICONBOX
Discussion