Design Patterns - Singleton and Dependency injection

Update to this entry: Added a new video to extend the discussion on Dependency Injection and show you how to inject instances through a constructor, field, property, and method.

Hey guys happy Sunday !

Today I released two new videos about using Singleton and Dependency Injection in our games. In this videos I walk you through step by step and explain how they are setup and why.

Take some time to view these videos and let me know if you have any questions.

How to use a singleton pattern in Unity3d and implement game managers

How To Use Dependency Injection In Unity3d with Zenject - Part 1

Dependency Injection pattern and injection types with Unity3d and Zenject - Part 2

Thanks!

 

I tried to summon out of this exactly why one would use a dependency injection. It looks like windoze business platform skullduggery and along with singletons see no use for them for someone who knows the Unity engine. It is coding, not programming. By this it means that it seems it is for the mere sake of coding gymnastics and does not seem to be programming of a solution. Convince me otherwise without 13 minutes of watching you type.

 

DI makes things
a) Easily unit testable
b) Easily implementation swappable

eg. if I'm making a unity app that has a box in a room that changes color depending on the temperature of the phone, I can have a TemperatureProvider injected.
a) I can test the provider to ensure it's spitting out the actual temperature of the phone, and can test the box to make sure it gets the correct colors per temperature
b) I can make a FakeTemperatureProvider hooked up to a slider, so I can demonstrate all possible box colors to a client without putting my phone in a fridge/oven

 

These are all good things. But I can do them all pretty easily without needing to have a DI system in place.

Can you give an example where DI helps to do something that doesn't have other, simpler solutions? I'm not asking this to undermine the usefulness of DI. I've seen it used in business applications to do really neat stuff, so I don't doubt its value in general. In regards to games in particular, though, I've asked a whole bunch of people similar questions and I've never actually got a good answer. Everyone seems to go quiet as soon as I ask how it compares to other solutions, rather than how it compares to nothing.

 

I would just write specific purpose components. Again..what problem does this solve? If it does not solve a problem with the Unity toolset then it is simply more convolution to suit enterprise programmer who want to haul their kit and kaboodle into the Unity game engine so they have familiar guideposts.

 

DI isn't necessarily a system, more a concept. The entire Unity editor, and kinda by extension you, are a dependency injector. When you drag and drop a reference into the OnClick method of a Button, you're injecting a dependency. DI is "the component doesn't make the elements it needs, something gives it to them", and this allows independence of resources.

Another common example is databases. Imagine some high score system, that saves high scores somewhere. For testing, I might want to save high scores to a json file locally, but for release, to a database in the cloud somewhere. The concept of "SaveHighScore(9001)" is independent of where the high score is saved, so I don't want to tie it down to either solution, or have to find-replace JsonDatabase.SaveHighScore to CloudDatabase.SaveHighScore all through my code. There are many ways to do it in Unity, but one might be that your HighScoreSystem has an IScoreDatabase field somewhere, and you can drop in either database implementation whenever you want.

It's not that it necessarily solves a problem with the Unity toolset; it's what the Unity toolset is and uses! See the above example of dropping a reference into a Button, or using ScriptableObjects to hold config data. It solves the problems that I listed above.

a) Testability. It allows devs to test components in isolation, and specific combinations of components. If you test your HighScoreSystem, and find that it accidentally runs in a loop and spams your high score database, would you rather that spam go to an InMemoryDatabase/JsonDatabase, or your real live cloud database?
b) Implementation swapping. I provided an example of where I'd use it. If all your interfaces work, and they're all tested, then you can just hot-swap them with minimal to no code changes. That's kinda the holy grail. Swapping between databases, or visual outputs, or input methods, becomes way easier and harder to mess up with DI, in general.

 

By your following description I use "Dependency Injection" all the time. Still, when developers suggest using DI I'm 99% sure they don't mean "use interfaces and/of the Unity Inspector". There's almost always something like Zenject being discussed.

 

That's a fair point. I might answer your question with a question, if you'll allow: Do you like the fact that you can substitute different implementations, or data, using the Unity inspector, in a type safe way? If so, consider using DI injectors such as Zenject, or at the very least, consider using classes with explicitly external dependencies (public MeshFilter MyMeshFilter) over internal ones (private MeshFilter MyMeshFilter = GetComponent<MeshFilter>()).


To note: Personally, I don't use Zenject, but I'd strongly consider it. I currently make good use of Odin, which can deal with interfaces in the inspector, which is a pretty good compromise.

 

Yeah, designing my stuff so that I can do in-editor configuration is really handy.

This is the bit that I don't understand. Again, it could be a lack of a concrete example.

If I make something visible in the Inspector, the way I see it I'm actually creating opportunities for errors. Someone could forget to hook it up. The wrong thing could be put in there. If it's public rather than just marked for Inspector visibility ("[SerializeField]") then other code could mess with it, and Unity already provides plenty of opportunites for that type of bug!

So I use stuff like GetComponent<>() and private fields a heck of a lot, too, because they solve problems that I did run into before. And, so far, I've not run into a problem where Inversion of Control or Dependency Injection came up or was suggested as a solution in the domain of game programming.

Maybe that's because, as you suggested already, I'm already using something pretty close to that in all of the cases where it's useful and I didn't even realise it. Or maybe it's because I'm stuck in a rut with outdated solutions. I'd just really love a concrete example along the lines of "our games had these issues, so we gave IoC/DI a go, and the issues were solved because XYZ." That's not meant as a challenge. I like making life easier for myself and understanding how different tools can help me do that.

 

When you drag and drop a concrete component to a interface property field in the editor thats IoC. When yuu do GetComponent on a interface thats IoC.

Its a bit of a poor mans DI though. Proper DI uses constructor injection. So that you can use readonly members that are ensured not to mutate. Plus with a DI container you can easily swap out components

 

Still can't see what problems this solves that I cannot already simply do. I have a GameObject. I want to swap components I do a Destroy(Component) and AddComponent. What performance gains would a user expect over the Unity standard method of doing things? If none then this is pure coding mental gymnastics. If some gain..why?

 

Not a runtime swap a compile time swap

lets say you have container.Bind<IMyInterface>().To<MyConcreteType>();

You can then just swap teh concrete type and the new type will be used without any change.

 

I don't know if it "solves" any specific problem, but let's say that you want to do something like re-rig up a bunch of components, and you want to set up some kind of automated process for switching stuff out.

Imagine you want to use some kind of configuration to control which components get swapped in or swapped out depending on different setups. For example, let's say you want to set up a mobile rig and a pc rig (or more likely you want to set up an automated testing rig and a playable rig).

You can use DI systems to arrange stuff like that. You kinda set up like a configuration specifying what classes to use where. Honestly, I think DI and testing really go hand in hand, and a big part of DI popularity is because to do automated testing - very often you need to rig up components in a way you never would "normally".

In order to do testing, you really need to support two different 'rigs' at minimum at all times. So something that makes it much easier to reconfigure the rigs saves a lot of headache.

Personally, I'm still not sold on automated testing in games, I think too much of it's too complex and interdependent. But ymmv.

 

Automated testing is good to catch most bugs, for example when refactoring, but those really funny bugs, for us mostly in connection with network code and timing is hard to catch. Sometimes when we find a bug we can write a test for it so it atleast can not happen again.

I always write a test to prove the bug before I go solve it.

 

This isn't for the user. It's about developer efficiency, which is also really important.

 

He's referring to the user of the Unity editor.

 

I would say most DI containers comes with a performance cost. In the business world Simple injector is regarded as the fastest one. And even that one comes with a overhead over simply instancing your objects. But if you allocate so many objects in one frame that it matters you are probably already allocating too much

https://simpleinjector.org/index.html

Another benefit of DI is lifetime and scope management. Transient lifetime is default in most containers, but you can overrride this to use for example http request life time. This is nice if you want to reuse the same entity framework context during the entire request and benefit from caching. You will scope it to the request and its lifetime is over when the request is over. Another benefit is custom scoping. For example a event aggregator that only lives in the context of a dialog in your UI. Then you can push events to all components in that window but windows outside will not receive the messages. We have manually fixed this in our game. All items the user can interact with are scoped so we have a event aggregator thats contexted to the item. Really useful when you want to communicate inside the item between components. Forexample when the fire selector wants to tell the firearm that it was changed to fully auto.

Also you might want to create on the fly local scopes for different domain reasons, I made a blog about how you can abstract away the container from the domain here https://andersmalmgren.com/2015/06/23/abstract-di-container-scopes/ and here a real world use case of it, https://andersmalmgren.com/2015/08/27/parallel-executed-tasks-with-isolated-scopes/

 

Update to this entry: Added a new video to extend the discussion on Dependency Injection and show you how to inject instances through a constructor, field, property, and method.

 

How would DI work with ECS?

This wikipedia article mentions the disadvantages of DI are...

• Dependency injection creates clients that demand configuration details be supplied by construction code. This can be onerous when obvious defaults are available.
• Dependency injection can make code difficult to trace (read) because it separates behavior from construction. This means developers must refer to more files to follow how a system performs.
• Dependency injection typically requires more upfront development effort since one can not summon into being something right when and where it is needed but must ask that it be injected and then ensure that it has been injected.
• Dependency injection forces complexity to move out of classes and into the linkages between classes which might not always be desirable or easily managed.[25]
• Dependency injection can encourage dependence on a dependency injection framework.[25][26][27]

Is it just moving the design complexity about or does it really provide a more adaptable framework?

It does sound like quite a bit of extra work, what type of game systems or even genres benefit best from DI?

 

Wiring up dependencies of more complex systems has been an issue for us, and it's certainly been solved through IoC. Which doesn't necessarily require an injection container. It can be as simple as a higher level object representing a system in your game (say, a spaceship in a space game that has engines, shields etc.) That higher level object then creates all its sub-system classes, deciding exactly what dependencies are used where and in which order every class should be initialized. That's inversion of control: low-level behaviour does not decide all by itself when it fires which functionality or even when it gets initialized. So, if you handle set-ups of more complex systems like that, you're already using IoC! Now, arguably, that may seem like a computer science obsession to label and name just about everything. Which, in a way, may be true, but if you think about it as a concept, it becomes much easier to find other places where you could use it and hopefully help untangle code.
DI, in theory at least, takes the single responsibility concept and IoC to an extreme. Essentially, setting up dependencies is a responsibility, so it's being handled separately. One advantage that is commonly touted is mocking for testing. But this doesn't even need to be automated testing, this can also be manual testing: We split up our game into various sub-modules that can function more or less by themselves. Because unity doesn't seem to handle projects well beyond a certain size (compiling times, general slowness...), we like to use Projeny and also split things up when working on those modules in the editor. With dependency injection, it's relatively straightforward to set up rules on when to use which stuff, e. g. based on preprocessor #ifdefs, so that all the other code won't ever really need to worry about it. That's certainly a win in my books and, were it not done in a separate place, would considerably clutter up and complicate other code.
And then it's also of course a matter of taste, but I think it's nice that my code is not cluttered up with instantiation and get component calls, which IMO makes it nicer and clearer to see what exactly that class does.

There aren't really any classes with cross-dependencies in ECS (which is one of its main benefits) and it has a very convenient way for systems to get the components/data they need.

Why not both?

It's not so much about genres, it's more about size. The bigger the project, the more I see a benefit in DI. For prototypes and small/simple games, I'd say that it's generally overkill and/or overengineering.

 

ECS aside these are the kinds of reasons I have not made much use of interfaces & DI - they slow me down.
Especially:
You can not trace through code so fast because if you hit an interface call you must then find the implementation.
If you update one implementation with a quick new feature requirement you must update all the others if they have a shared interface.

I would like more separation of code but a lot of the code you write will always work outside of the core app code as it is naturally generic and so can be testable alone.

I could not work without Singletons for similar reasons.

But if I could find an architecture bible that could show me how to code fast, as well as use DI (and maybe no Singletons) I would be happy to read.

 

Hi just to say on the singleton - you have it as a monobehaviour but no need in this case, a simple class will do. If you have to have a monobehaviour singleton then you do not want to allocate a new instance, you would want to set _instance = this; in the Awake function perhaps.

 

I like to code games as simply as I can. I don't stress about performance, just convenience for me. If I need a tool, I make a basic one that suits my needs. If I think a problem is simple, I believe the solution should be equally simple.

Sometimes simple is pretty technical, sometimes it's an array of raycasts, sometimes it's a logic puzzle... but as long as it works, I know I will have fewer bugs and more stable code in the future.

Singletons are simple. They are an example of great power requiring great responsibility.

 

How is that related to dependency injection? And that's a key point about interfaces. They are a contract about provided functionality. If you need more functionality that other implementations don't offer, you might want to consider creating another interface for that. I also don't get the part about tracing code - if you debug and you step through code, it should step into the methods of the concrete implementations of that interface. Same thing if you actually throw an exception - your stack trace should only show the call of that method as a call to an interface, anything triggered inside that method should also display as part of the actual implementation.

If you depend on singletons, your code cannot easily be tested alone.

Game programming patterns is a pretty good place to start.

Anyway, as this has been popping up over and over again in this thread, as well as pretty much every other thread on design patterns and software architecture on this forum and on reddit:

• Software architecture takes time and practice to understand and implement
  
• Like with everything else, if you implement them on a regular basis, you will become a lot faster and better at it.
  
• If you put together a quick prototype or a small game using all these great and powerful tools unity gives you, using elaborate architecture will slow you down.
• This is important: In bigger software projects and with larger teams, the cost of software development is not creating new code, it is expanding, fixing and rewriting old code.

What does that mean in practice? Know your requirements. If all you work on are small prototypes, visualizations and games, you're not too concerned with reusing code and you don't work with a lot of people, you don't need to invest time in architecture. Essentially, you can build a pretty sweet garden shed without much of a clue about architecture, especially when using great tools like Unity.
But large game projects, maybe even with planned sequels and distributed studios, are more on the 'skyscraper' end of things. At some point, they're going to crumble if little to no thought has been put into their structure. If you work on long-scale game projects and/or you want your code base to be shared with more programmers in the future, you will most likely save time and headaches by using software engineering/architecture principles. Seriously, they exist for a reason and it's not just because some programmers just like to feel smart.

 

Related because interfaces a key part of DI? I see your point on provided functionality, the problem is you usually do not know what that is - it continually changes as you develop.

Debugging is fine but tracing through code outside of a running app is harder.

 

'How is that related' was the wrong question to ask. The point I was trying to make was that it's an 'issue' with interfaces in general, which are really a much broader and general concept than DI containers (seeing how it's a built-in feature in C#, C++...)

Yep, and that's what makes interfaces powerful. They are contracts, semi-rigidly fixed junctions around which you can then build a more agile code-base. And of course, if you use them as such, it's a harder decision if new functionality should be part of an existing interface or if it warrants an interface of its own. In my opinion though, that gets people to think about how different parts of their software are related, how these parts interact and where that new functionality fits in the grand scheme of things. Which, in the end, likely leads to a better understanding and better structure of the code-base.

 

Yes. Odin is awesome but you can not utilize it for Monobehaviours and scriptableObjects implementing interfaces.
It can only be used for pure C# classes implementing interfaces. However it is cool for handling interfaces

 

pls programmer gods, can you be very very specific to the point that like when i learn about scriptable object ( that i immediately fallen in love with and use extensively lately ).
how i learn that ? i learn by example, like to define a scriptable object to hold data for goblin A with 40 hp and 30 atk. But then i can dupplicate ( Ctrl+D ) that goblin A and name it HobGoblin , with 1000 hp and 100 atk and so on. That's the beautiful thing of learning from example, immediately see the usecase.
So again pls use usecase to explain me this DI thing, thanks alot. These walls of texts above me made me confused.

 

There are a lot of DI topics that explain better than us.

 

DI helps in many code quality areas. Check out this answer I did on SO

https://codereview.stackexchange.co...y-pattern-photo-gallery-example/216851#216851

Orignal code (In direct violation of open/closed principle):

Code (CSharp):

1.     private void SetShareStrategy(ShareStrategy strategy)
2.    {
3.        switch (strategy)
4.        {
5.            case ShareStrategy.onFacebook:
6.                this.shareStrategy = new ShareOnFacebook();
7.                break;
8.            case ShareStrategy.onInstagram:
9.                this.shareStrategy = new ShareOnInstagram();
10.                break;
11.            case ShareStrategy.onTwitter:
12.                this.shareStrategy = new ShareOnTwitter();
13.                break;
14.        }
15.    }

My suggestion solution

Code (CSharp):

1. serviceCollection
2.    .AddTransient<IShareStrategy, ShareOnFacebook>()
3.    .AddTransient<IShareStrategy, ShareOnTwitter>()
4.    .AddTransient<IShareStrategyProvider, ShareStrategyProvider>();
5.  
6. public class ShareStrategyProvider : IShareStrategyProvider
7. {
8.    private readonly IEnumerable<IShareStrategy> _strategies;
9.    public ShareStrategyProvider(IEnumerable<IShareStrategy> strategies)
10.    {
11.       _strategies = strategies;
12.    }
13.  
14.    public GetStrategy(ShareStrategy sharingStrategy);
15.    {
16.       return _strategies.Single(s => s.SharingStrategy == sharingStrategy);
17.    }
18. }

 

DI has costs. Loading times is the con as reflection is heavy unless done correctly.
More classes and methods -> longer loading times.
Sometimes they can get as absurd as 90+ (!!!) seconds of loading time on mobile.

If you really want your game to be fast - avoid DI. It's just not worth it.
In business world it might be worth doing because it creates pseudo-maintainability. (Which is, debatable).

Also, it's like using a nuke to kill a fly. Will it kill it? For sure. Is it efficient to use? No, not really.

 

Not for a large project. Dependency is not a fly for a large project

 

Yeah, large as GTA 5, maybe.

 

Map scale has nothing Todo with it, I ment project complexity

 

Same, GTA 5 is quite a complex project.
It has to have about the same scale (including multiplayer) to justify performance loss from DI.

 

Its complexity comes from world scale, streaming etc. Not domain complexity. We dont use DI in our game, but we use inversion of control. We can benefit from it pretty well without a DI-container because our game is modular built and the lowest bulding block in that system has a crude custom DI. I wouldn't worry that much about performance though. You dont allocate that much in each frame, and if you are you have other problems than dependency injection.

 

We also use inversion of control for our netcode. It was a no brainer retrofixing singeplayer tutorial, just implement a dummy networker thats injected in the lobby.

 

90 seconds? Would be quite curious what kind of project that is...

 

Thread.Sleep(90000) in the constructor

 

Just remembered another project that had Thread.Sleep instead of coroutines everywhere.

Ah, good times. Outsource knows on how to deliver.

Medium sized mobile game. With DI on top of it.
Low-end devices crapped themselves real hard. It was a while back though, so the things might have changed.

Still, I would expect that loading time would raise drastically with DI.
It depends on what DI is used. Some frameworks aren't that bad.

For PC / Consoles it might be ok, but I wouldn't recommend using it for small or mobile projects though.
It's just me and my subjective opinion.

 

A few years back I noticed that a system went unresponsive and the CPU usage went to the roof. I pin pointed it down to that some code monkey had done

Code (CSharp):

1. var waitUntil = DateTime.Now.AddMinutes(10);
2. while(waitUntil > DateTime.Now) {}

(Or similar, coded out of memory). haha. I wasn't impressed

 

Honestly though, you dont have that many systems that need dependency that it could be a real problem. We use inversion of control on maybe 5 places in our game, the netcode, the event bus and some more places. Maybe we would use it a bit more if we had proper DI, but 90 seconds, thats a few million instances even on mobile. It cant be DI alone thats the problem.¨

edit: Its not like in a business app were each api call spawns alot of DI calls. In a game its more when you load the level etc. WHen the level is loaded the objects are in memory