Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Zenject Example ~さよならManager編~
Search
いも
August 26, 2019
Programming
1
1.7k
Zenject Example ~さよならManager編~
Roppongi.unity #04 で発表した資料です
いも
August 26, 2019
Tweet
Share
More Decks by いも
See All by いも
UnityプログラミングバイブルR6号宣伝&Unity Logging小話
adarapata
0
430
Unityテスト活動のふりかえり
adarapata
1
530
Gather.townはいいぞ その後
adarapata
1
1.5k
Unityでの開発事例
adarapata
3
22k
どこのご家庭にもあるシーンマネージャーの話
adarapata
1
7.6k
Gather.townはいいぞ
adarapata
2
2.3k
宴はいいぞ
adarapata
0
1.3k
わかった気になるモブプログラミング
adarapata
1
98
モブワークっぽいのをやっている話/Trying mobwork
adarapata
2
1.2k
Other Decks in Programming
See All in Programming
Bedrock Agentsレスポンス解析によるAgentのOps
licux
3
840
データベースのオペレーターであるCloudNativePGがStatefulSetを使わない理由に迫る
nnaka2992
0
150
Pulsar2 を雰囲気で使ってみよう
anoken
0
240
Software Architecture
hschwentner
6
2.1k
DROBEの生成AI活用事例 with AWS
ippey
0
130
コミュニティ駆動 AWS CDK ライブラリ「Open Constructs Library」 / community-cdk-library
gotok365
2
140
GoとPHPのインターフェイスの違い
shimabox
2
190
技術を根付かせる / How to make technology take root
kubode
1
250
SwiftUIで単方向アーキテクチャを導入して得られた成果
takuyaosawa
0
270
Honoのおもしろいミドルウェアをみてみよう
yusukebe
1
210
Amazon Bedrock Multi Agentsを試してきた
tm2
1
290
PHPカンファレンス名古屋2025 タスク分解の試行錯誤〜レビュー負荷を下げるために〜
soichi
1
200
Featured
See All Featured
Statistics for Hackers
jakevdp
797
220k
Large-scale JavaScript Application Architecture
addyosmani
511
110k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
114
50k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Why Our Code Smells
bkeepers
PRO
336
57k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
193
16k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
1k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
366
25k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Transcript
Zenject Example ~さよならManager ~ いも(@adarapata) 2019/08/26 Roppongi.unity #04 1
今日話すこと Manager をZenject 使って滅ぼす話 Zenject を多少知ってる人向け 2019/08/26 Roppongi.unity #04 2
どこのご家庭にもあるMasterDataManager public class MasterDataManager : SingletonMonoBehaviour<MasterDataManager> { public List<PlayerData> Players
{ get; private set; } public List<EnemyData> Enemies { get; private set; } public List<ItemData> Items { get; private set; } private CsvLoader _provider; public PlayerData FindById(int id) => Players.Find(p => p.id == id); void Start() { Players = _provider.LoadAll<PlayerData>("path/to/players"); Enemies = _provider.LoadAll<EnemyData>("path/to/enemies"); Items = _provider.LoadAll<ItemData>("path/to/items"); } } 2019/08/26 Roppongi.unity #04 3
MasterDataManager の気になるポイント 責務が多い インスタンスを持つだけでなく便利メソッド生え始めた 今後あらゆるデータが追加されて肥大する香りがする テスタビリティが低い 1 メソッドテストするのに複数の要素が必要になる static なのでMasterDataManager
に依存しているコード側もテス トしにくい 2019/08/26 Roppongi.unity #04 4
MasterDataManaer の立ち位置を考える なぜMasterDataManager という名前がついてたのか? 複数の種類のデータクラスを纏めて持っているから なぜ複数の種類のデータを持ってたのか? 全部ユニークなインスタンスなのでSingleton なインスタンスに持 たせた方が楽 なぜSingleton
なのか いろんなところから簡単にアクセスできるようにしたい 各依存先に渡すのが大変だから これらを解決できるならばManager は不要になる 2019/08/26 Roppongi.unity #04 5
やっていくぞ 2019/08/26 Roppongi.unity #04 6
まずはテスト namespace Tests { public class MasterDataManagerTest { private MasterDataManager
_manager; [UnityTest] public IEnumerator FindById_Success() { _manager = new GameObject().AddComponent<MasterDataManager>(); yield return new WaitForEndOfFrame(); var playerData = _manager.FindById(1); Assert.AreEqual("Foo", playerData.name); } } } 2019/08/26 Roppongi.unity #04 7
コードのお気持ちを探る なぜSingleton なの? ← イマココ なぜMonoBehaviour なの? 2019/08/26 Roppongi.unity #04
8
なぜSingleton なの? いろんなところから簡単にアクセスできるようにしたい 各依存先に渡すのが大変だから これを解決できるならばSingleton である必要はない。 じゃあDI しましょう。 2019/08/26 Roppongi.unity
#04 9
MasterDataManager をBind する まだMonoBehaviour なのでZenject Binding でサッとやる 2019/08/26 Roppongi.unity #04
10
Project Context を作って子にする 2019/08/26 Roppongi.unity #04 11
呼ぶ側が書き直せる public class FooBehaviour { public void Foo(){ var player
= MasterDataManager.Instance.FindById(1); } } ↓ public class FooBehaviour { [Inject] private MasterDataManager manager; public void Foo(){ var player = manager.FindById(1); } } 2019/08/26 Roppongi.unity #04 12
全箇所移行完了したらMonoBehaviour に書き直す public class MasterDataManager : MonoBehaviour { public List<PlayerData>
Players { get; private set; } public List<EnemyData> Enemies { get; private set; } public List<ItemData> Items { get; private set; } private CsvLoader _provider; public PlayerData FindById(int id) => Players.Find(p => p.id == id); void Start() { Players = _provider.LoadAll<PlayerData>("path/to/players"); Enemies = _provider.LoadAll<EnemyData>("path/to/enemies"); Items = _provider.LoadAll<ItemData>("path/to/items"); } } 2019/08/26 Roppongi.unity #04 13
コードのお気持ちを探る なぜSingleton なの? :done: なぜMonoBehaviour なの? ← イマココ 2019/08/26 Roppongi.unity
#04 14
なぜMonoBehaviour なの? 初期化処理( ロード部分) を呼びたい 誰も初期化を呼ぶ人がいないのでStart() を使いたい これを解決できるならばMonoBehaviour である必要はない。 2019/08/26
Roppongi.unity #04 15
IInitializable を実装してみよう public class MasterDataManager : MonoBehaviour, IInitializable { public
List<PlayerData> Players { get; private set; } public List<EnemyData> Enemies { get; private set; } public List<ItemData> Items { get; private set; } private CsvLoader _provider; public PlayerData FindById(int id) => Players.Find(p => p.id == id); public void Initialize(){ Players = _provider.LoadAll<PlayerData>("path/to/players"); Enemies = _provider.LoadAll<EnemyData>("path/to/enemies"); Items = _provider.LoadAll<ItemData>("path/to/items"); } } 2019/08/26 Roppongi.unity #04 16
IInitializable Zenject が提供するinterface やることは初期化のみ 実装すると、依存関係解決後にInitialize() をコールしてくれる 裏側でInitializableManager が動いてる。 2019/08/26 Roppongi.unity
#04 17
不要になったのでMonoBehaviour をやめよう public class MasterDataManager : IInitializable { public List<PlayerData>
Players { get; private set; } public List<EnemyData> Enemies { get; private set; } public List<ItemData> Items { get; private set; } private CsvLoader _provider; public PlayerData FindById(int id) => Players.Find(p => p.id == id); public void Initialize(){ Players = _provider.LoadAll<PlayerData>("path/to/players"); Enemies = _provider.LoadAll<EnemyData>("path/to/enemies"); Items = _provider.LoadAll<ItemData>("path/to/items"); } } 2019/08/26 Roppongi.unity #04 18
MonoBehaviour じゃなくなったのでInstaller を書こう public class MasterDataInstaller : MonoInstaller { public
override void InstallBindings() { Container.Bind<MasterDataManager>().AsSingle(); } } 2019/08/26 Roppongi.unity #04 19
テストも少し書き直そう namespace Tests { public class MasterDataManagerTest { private MasterDataManager
_manager; // MonoBehaviour じゃないのでEditTest で十分 [Test] public void FindById_Success() { _manager = new MasterDataManager(); _manager.Initialize(); var playerData = _manager.FindById(1); Assert.AreEqual("Foo", playerData.name); } } } 2019/08/26 Roppongi.unity #04 20
今一度MasterDataManaer の立ち位置を考える なぜMasterDataManager という名前がついてたのか? 複数の種類のデータクラスを纏めて持っているから なぜ複数の種類のデータを持ってたのか? 全部ユニークなインスタンスなのでSingleton なインスタンスに持 たせた方が楽 なぜSingleton
なのか いろんなところから簡単にアクセスできるようにしたい 各依存先に渡すのが大変だから 2019/08/26 Roppongi.unity #04 21
今一度MasterDataManaer の立ち位置を考える なぜSingleton なのか => DI でOK なぜ複数の種類のデータを持ってたのか? => 直接Inject
できるなら 纏める必要はない なぜMasterDataManager という名前がついてたのか? => 纏める必 要ないなら不要では? 2019/08/26 Roppongi.unity #04 22
データ持ってるクラスを独立 public class PlayerDataRepository { private readonly List<PlayerData> _resources; public
PlayerDataRepository(IResourceLoadProvider _provider) { _resources = _provider.LoadAll<PlayerData>("path/to/players"); } public PlayerData FindById(int id) => _resources.Find(p => p.id == id); } public class MasterDataInstaller : MonoInstaller { public override void InstallBindings() { Container.BindInterfacesAndSelfTo<MasterDataManager>().AsSingle(); Container.BindInterfacesAndSelfTo<PlayerDataRepository>().AsSingle(); Container.Bind<IResourceLoadProvider>().To<CsvLoader>().AsSingle(); } } 2019/08/26 Roppongi.unity #04 23
PlayerDataRepository だけ差し替えて動作は変えない public class MasterDataManager : IInitializable { public List<EnemyData>
Enemies { get; private set; } public List<ItemData> Items { get; private set; } [Inject] private IResourceLoadProvider _provider; [Inject] private PlayerDataRepository _playerDataRepository; public PlayerData FindById(int id) => _playerDataRepository.FindById(id); public void Initialize() { Enemies = _provider.LoadAll<EnemyData>("path/to/enemies"); Items = _provider.LoadAll<ItemData>("path/to/items"); } } 2019/08/26 Roppongi.unity #04 24
新規に書くときは直接Repository を渡してあげればよい public class FooBehaviour { [Inject] private PlayerDataRepository _repository;
public void Foo(){ var player = repository.FindById(1); } } 2019/08/26 Roppongi.unity #04 25
Test もZenject 対応 public class MasterDataManagerTest : ZenjectUnitTestFixture { public
class MockLoader : IResourceLoadProvider { public List<T> LoadAll<T>(string path) => new List<T>(/* なんかいい感じ生成 */); } private MasterDataManager _manager; [Test] public void FindById_Success() { Container.Bind<MasterDataManager>().AsSingle(); Container.BindInterfacesTo<MockLoader>().AsSingle(); Container.Bind<PlayerDataRepository>().AsSingle(); _manager = Container.Resolve<MasterDataManager>(); _manager.Initialize(); var playerData = _manager.FindById(1); Assert.AreEqual("Foo", playerData.name); } } 2019/08/26 Roppongi.unity #04 26
さよならManager 2019/08/26 Roppongi.unity #04 27
まとめ Zenject 使えばインスタンスを集約するだけのクラスは不要になる Manager と呼ばれてるものの役割を見直してみよう もしかしたらインスタンスを集めてるだけのクラスかもしれない 漸進的に変更できる方法を選ぼう 旧コードと新コードが一時は同居できるようにする テストを書くと安心感ある テストを書くと安心感ある
テストを書くと安心感ある 2019/08/26 Roppongi.unity #04 28
宣伝 Zenject 本書いてます 技術書典7 こ20D 前後編になりました 〆切と印刷費に負けた ごめん 今回は前編を出します DI
の話~Scene 跨ぎのBind くらいまで 2019/08/26 Roppongi.unity #04 29