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.8k
Zenject Example ~さよならManager編~
Roppongi.unity #04 で発表した資料です
いも
August 26, 2019
Tweet
Share
More Decks by いも
See All by いも
UnityプログラミングバイブルR6号宣伝&Unity Logging小話
adarapata
0
570
Unityテスト活動のふりかえり
adarapata
1
580
Gather.townはいいぞ その後
adarapata
1
1.6k
Unityでの開発事例
adarapata
3
23k
どこのご家庭にもあるシーンマネージャーの話
adarapata
1
8.2k
Gather.townはいいぞ
adarapata
2
2.4k
宴はいいぞ
adarapata
0
1.5k
わかった気になるモブプログラミング
adarapata
1
120
モブワークっぽいのをやっている話/Trying mobwork
adarapata
2
1.3k
Other Decks in Programming
See All in Programming
AI Agent 時代的開發者生存指南
eddie
2
1.6k
チームの境界をブチ抜いていけ
tokai235
0
180
登壇は dynamic! な営みである / speech is dynamic
da1chi
0
340
CSC509 Lecture 05
javiergs
PRO
0
300
All About Angular's New Signal Forms
manfredsteyer
PRO
0
170
Go言語の特性を活かした公式MCP SDKの設計
hond0413
1
230
(Extension DC 2025) Actor境界を越える技術
teamhimeh
1
260
Foundation Modelsを実装日本語学習アプリを作ってみた!
hypebeans
0
110
Android16 Migration Stories ~Building a Pattern for Android OS upgrades~
reoandroider
0
110
なぜGoのジェネリクスはこの形なのか? Featherweight Goが明かす設計の核心
ryotaros
7
1.1k
NixOS + Kubernetesで構築する自宅サーバーのすべて
ichi_h3
0
950
Go Conference 2025: Goで体感するMultipath TCP ― Go 1.24 時代の MPTCP Listener を理解する
takehaya
9
1.7k
Featured
See All Featured
Optimizing for Happiness
mojombo
379
70k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
A Modern Web Designer's Workflow
chriscoyier
697
190k
The Illustrated Children's Guide to Kubernetes
chrisshort
49
51k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.2k
Rails Girls Zürich Keynote
gr2m
95
14k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
37
2.6k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.2k
Six Lessons from altMBA
skipperchong
29
4k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
How GitHub (no longer) Works
holman
315
140k
Making Projects Easy
brettharned
120
6.4k
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