{"id":73,"date":"2021-10-24T07:45:26","date_gmt":"2021-10-24T07:45:26","guid":{"rendered":"https:\/\/docs.sisus.co\/inity\/?p=73"},"modified":"2026-01-08T07:19:34","modified_gmt":"2026-01-08T07:19:34","slug":"why-init-args","status":"publish","type":"post","link":"https:\/\/docs.sisus.co\/init-args\/introduction\/why-init-args\/","title":{"rendered":"2. Why Init(args)?"},"content":{"rendered":"

To fully grasp the advantages that Init(args) can unlock, it’s essential to first understand a key design principle in software engineering: inversion of control<\/strong>.<\/p>\n

In a nutshell, inversion of control means that instead of classes independently retrieving the objects they need, those objects are provided to them by other classes.<\/p>\n

This approach comes with several benefits, such as making it very easy to swap out delivered objects with different ones.<\/p>\n

Typically, inversion of control can be achieved by passing the objects that a client needs to it via its constructor:<\/p>\n

using <\/b><\/span><\/span>UnityEngine;\r\n<\/span><\/span>\r\nclass <\/b><\/span>Player<\/span><\/span>\r\n{<\/span>\r\n    IInputManager InputManager;<\/span><\/span><\/span>\r\n    Camera Camera;<\/span><\/span><\/span>\r\n\r\n    public Player<\/span><\/span><\/b>(<\/span><\/span><\/b><\/span><\/span>IInputManager inputManager,<\/span> Camera camera<\/span>)<\/span><\/span>\r\n    {<\/span><\/span>\r\n        this<\/b><\/span>.<\/span>inputManager =<\/span> inputManager<\/span>;\r\n<\/span><\/span>        this<\/b><\/span>.<\/span>camera =<\/span> camera;<\/span><\/span>\r\n    }<\/span><\/span>\r\n}<\/span><\/pre>\n
However, Unity\u2019s MonoBehaviour<\/span> or ScriptableObject<\/span> classes don’t support constructor arguments, making it challenging to apply inversion of control.<\/p>\n
This situation often leads developers to rely on things like the Singleton<\/strong> pattern instead, leading to classes being rigidly bound together in a tangled web of dependencies.<\/p>\n
using <\/b><\/span><\/span>UnityEngine;<\/span><\/span>\r\n\r\nclass<\/b><\/span> Player :<\/span> MonoBehaviour<\/span>\r\n{<\/span>\r\n    void<\/b><\/span> Update<\/span>()<\/span><\/span>\r\n    {<\/span>\r\n        if<\/b><\/span>(<\/span>InputManager.Instance.<\/span>Input.<\/span>y ><\/span> 0f)<\/span><\/span>\r\n        {<\/span><\/span>\r\n            var<\/b><\/span> speed <\/span>=<\/span> 0.2<\/span>f<\/span>;<\/span><\/span>\r\n            var<\/b><\/span> distance <\/span>=<\/span> Time<\/span>.<\/span>deltaTime <\/span>*<\/span> speed<\/span>;\r\n<\/span><\/span>            transform.<\/span>Translate(<\/span>Camera.<\/span>main.<\/span>transform.<\/span>forward *<\/span> distance);\r\n<\/span><\/span><\/span>        }\r\n    }<\/span>\r\n}<\/span><\/pre>\n
While this does accomplish the job of retrieving the instance, it also comes with some pretty severe negative side effects that may end up hurting you in the long run – especially in larger projects.<\/p>\n
\ud83d\udd0d Hidden Dependencies<\/strong><\/h4>\n
Dependencies are scattered all over the class rather than being clearly and statically defined in one place. This obscures what requirements must be met for the component to function correctly.<\/p>\n
For example, while you can instantiate the above Player<\/code> at any time using GameObject.AddComponent()<\/code>, or attach it to any GameObject using the Inspector, there’s no way for you to know in either case that an InputManager<\/code> and a main camera must also exist somewhere in the scene for it to actually work!<\/p>\n
\ud83e\uddea Testability<\/strong><\/h4>\n
It tends to make it near impossible to write unit tests. If the Player class depends on a specific InputManager singleton object, you can\u2019t swap it with a simpler test double during tests, nor modify it its state in any way without the potential for undesired side effects.<\/p>\n
\ud83d\udd27 Maintainability<\/h4>\n
If you need to change a service to a different one – say, InputManager<\/code> to\u00a0NewInputSystemManager<\/code> –\u00a0you’ll need to update every class that uses the old one.<\/p>\n
<\/p>\n
\ud83e\udde9 Adaptability<\/strong><\/h4>\n
You lose the flexibility to swap implementations based on context, such as using MobileInputManager<\/code>on mobile platforms and PCInputManager<\/code> on desktop platforms.<\/p>\n
\ud83d\udeabReusability<\/strong><\/h4>\n
Tightly coupled systems are harder to reuse across projects. For instance, if your CameraController<\/code> depends on several other specific classes, which all depend on several other specific classes, you won’t be able to migrate it to another project without a lot of rewriting.<\/p>\n
Enter Init(args)<\/h2>\n
<\/p>\n
Init(args) addresses all of these issues by making it trivial to achieve inversion of control in Unity, with the introduction of the new\u00a0Init<\/b> function<\/strong>:<\/p>\n
using <\/span>Sisus.<\/span>Init;<\/span><\/span>\r\n\r\n<\/b><\/span>class<\/b><\/span> Player <\/span>:<\/span> MonoBehaviour<\/span><<\/span><\/span>IInputManager, Camera><\/span><\/span>\r\n{\r\n<\/span>    IInputManager inputManager;<\/span>\r\n    Camera camera;<\/span>\r\n\r\n    protected override void<\/b><\/span> Init<\/span>(<\/span><\/span>IInputManager inputManager, Camera camera)\r\n<\/span><\/span>    {\r\n<\/span><\/span>            this<\/b><\/span>.<\/span>inputManager =<\/span> inputManager<\/span>;\r\n<\/span><\/span>            this<\/b><\/span>.<\/span>camera =<\/span> camera;<\/span>\r\n<\/span>    }\r\n}<\/span><\/pre>\n
This makes all dependencies explicit, and makes the code testable, modular and maintainable by default.<\/p>\n","protected":false},"excerpt":{"rendered":"
To fully grasp the advantages that Init(args) can unlock, it’s essential to first understand a key design principle in software engineering: inversion of control. In a nutshell, inversion of control means that instead of classes independently retrieving the objects they need, those objects are provided to them by other classes. This approach comes with several ..<\/p>\n
<\/div>\n
Read more<\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[3],"tags":[],"_links":{"self":[{"href":"https:\/\/docs.sisus.co\/init-args\/wp-json\/wp\/v2\/posts\/73"}],"collection":[{"href":"https:\/\/docs.sisus.co\/init-args\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/docs.sisus.co\/init-args\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/docs.sisus.co\/init-args\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/docs.sisus.co\/init-args\/wp-json\/wp\/v2\/comments?post=73"}],"version-history":[{"count":25,"href":"https:\/\/docs.sisus.co\/init-args\/wp-json\/wp\/v2\/posts\/73\/revisions"}],"predecessor-version":[{"id":1092,"href":"https:\/\/docs.sisus.co\/init-args\/wp-json\/wp\/v2\/posts\/73\/revisions\/1092"}],"wp:attachment":[{"href":"https:\/\/docs.sisus.co\/init-args\/wp-json\/wp\/v2\/media?parent=73"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/docs.sisus.co\/init-args\/wp-json\/wp\/v2\/categories?post=73"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/docs.sisus.co\/init-args\/wp-json\/wp\/v2\/tags?post=73"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}