{"id":28,"date":"2021-07-19T16:28:54","date_gmt":"2021-07-19T16:28:54","guid":{"rendered":"https:\/\/docs.sisus.co\/inity\/?p=28"},"modified":"2025-08-23T06:48:53","modified_gmt":"2025-08-23T06:48:53","slug":"monobehaviour-t","status":"publish","type":"post","link":"https:\/\/docs.sisus.co\/init-args\/clients\/monobehaviour-t\/","title":{"rendered":"1. MonoBehaviour<T…>"},"content":{"rendered":"

\"\"<\/h2>\n

Init(args) extends the MonoBehaviour class with the\u00a0ability to receive up to twelve arguments during its initialization, before any of its lifetime events are executed.<\/p>\n

To enable your component to receive objects passed to it from the outside, make the class derive from MonoBehaviour<><\/code>, and list the types of all the objects needed as generic type arguments of the base class. Next implement the Init method, where all the required objects will be received.<\/p>\n

In the example below, the Player<\/code> object can receive three objects during its initialization: IInputManager<\/code>, Camera<\/code> and Collider<\/code>.<\/p>\n

using<\/span> Sisus.<\/span>Init;<\/span><\/span>\r\nusing<\/span> UnityEngine;<\/span><\/span>\r\n\r\nclass<\/span> Player<\/span> :<\/span> MonoBehaviour<<\/span>IInputManager,<\/span> Camera,<\/span> Collider><\/span><\/span>\r\n{<\/span><\/span>\r\n   IInputManager inputManager;<\/span><\/span>\r\n   Camera camera;<\/span><\/span>\r\n   Collider collider;<\/span><\/span>\r\n\r\n   protected<\/span> override<\/span> void<\/span> Init<\/span>(<\/span>IInputManager inputManager,<\/span> Camera camera,<\/span> Collider collider)<\/span><\/span>\r\n   {<\/span><\/span>\r\n      this<\/span>.<\/span>inputManager =<\/span> inputManager;<\/span><\/span>\r\n      this<\/span>.<\/span>camera =<\/span> camera;<\/span><\/span>\r\n      this<\/span>.<\/span>collider =<\/span> collider;<\/span><\/span>\r\n   }<\/span><\/span>\r\n}<\/span><\/span><\/pre>\n
The Init function gets executed when the object is being initialized, before the Awake<\/a> or OnEnable<\/a> events.<\/p>\n
Initialization Logic<\/h2>\n
The below chart describes how each Init<\/strong> method argument is resolved when a client that derives from MonoBehaviour<T...><\/code> is being loaded:<\/p>\n

\n\"Client
\n<\/a><\/p>\n
Additionally, if arguments are passed in code<\/a> via AddComponent<\/code> or Instantiate<\/code>, then those will be passed to the Init method instead.<\/p>\n
Asynchronous Initialization<\/h2>\n
By default, if any services that a component depends on are not available when the component is being loaded, the execution of all its lifetime events (including Awake, OnEnable and Start) will be deferred until all the services have become available.<\/p>\n
This functionality can be disabled for components by adding the [Init] attribute<\/a> to its class and setting WaitForServices<\/strong> to false<\/strong>.<\/p>\n
OnAwake<\/b><\/span><\/span><\/span><\/h2>\n
The MonoBehaviour<T…> base class automatically receives Init arguments that have been injected to the object in its Awake<\/a> method. It then first passes the received arguments to the Init method, and after that executes the OnAwake method.<\/p>\n
If you want to execute code during the Awake lifetime event in a component that derives from MonoBehaviour<T..>, you should override the OnAwake method, instead of defining a new Awake method:<\/p>\n
class<\/span> Player<\/span> :<\/span> MonoBehaviour<<\/span>IInputManager><\/span><\/span>\r\n{<\/span><\/span>\r\n   IInputManager inputManager;<\/span><\/span>\r\n\r\n   protected<\/span> override<\/span> void<\/span> Init(<\/span>IInputManager inputManager)<\/span> =<\/span>><\/span> this<\/span>.<\/span>inputManager =<\/span> inputManager;<\/span><\/span>\r\n\r\n   protected<\/span> override<\/span> void<\/span> OnAwake(<\/span>)<\/span> =<\/span>><\/span> Debug.<\/span>Log(<\/span>$\"<\/span>I can use <\/span>{<\/span>inputManager<\/span>}<\/span> in OnAwake!<\/span>\"<\/span>)<\/span>;<\/span><\/span>\r\n   void<\/span> OnEnable(<\/span>)<\/span> =<\/span>><\/span> Debug.<\/span>Log(<\/span>$\"<\/span>I can use <\/span>{<\/span>inputManager<\/span>}<\/span> in OnEnable!<\/span>\"<\/span>)<\/span>;<\/span><\/span>\r\n   void<\/span> Start(<\/span>)<\/span> =<\/span>><\/span> Debug.<\/span>Log(<\/span>$\"<\/span>I can use <\/span>{<\/span>inputManager<\/span>}<\/span> in Start!<\/span>\"<\/span>)<\/span>;<\/span><\/span>\r\n}<\/span><\/span><\/pre>\n
OnReset<\/b><\/span><\/span><\/span><\/h2>\n
Similarly, the MonoBehaviour<T…> base class already defines a Reset<\/a> method, to support the InitOnReset<\/a> feature.<\/p>\n
If you want to execute code during the Reset lifetime event in a component that derives from MonoBehaviour<T..>, you should override the OnReset method, instead of defining a new Reset method:<\/p>\n
class<\/span> Player<\/span> :<\/span> MonoBehaviour<<\/span>IInputManager><\/span><\/span>\r\n{<\/span><\/span>\r\n   IInputManager inputManager;<\/span><\/span>\r\n   [SerializeField] Collider collider;<\/span><\/span>\r\n\r\n   protected<\/span> override<\/span> void<\/span> Init(<\/span>IInputManager inputManager)<\/span> =<\/span>><\/span> this<\/span>.<\/span>inputManager =<\/span> inputManager;<\/span><\/span>\r\n\r\n   protected<\/span> override<\/span> void<\/span> OnReset(<\/span>)<\/span> =<\/span>><\/span> collider =<\/span> GetComponent<<\/span>Collider><\/span>(<\/span>)<\/span>;<\/span><\/span>\r\n}<\/span><\/span><\/pre>\n
AddComponent with Arguments<\/b><\/span><\/span><\/h2>\n
Init(args) extends the GameObject<\/a> type with new AddComponent methods that allow passing Init arguments to the created component.<\/p>\n
To do so, list the types of the Init parameters after the type of the added component, and pass in the objects you want as arguments of the method:<\/p>\n
gameObject.<\/span>AddComponent<<\/span>Player,<\/span> IInputManager,<\/span> Camera><\/span>(<\/span>inputManager,<\/span> camera)<\/span>;<\/span><\/span><\/pre>\n
Alternatively, you can use an AddComponent variant which assigns the created component into an out parameter, instead of return it.<\/p>\n
gameObject.<\/span>AddComponent(<\/span>out<\/span> Player player,<\/span> inputManager,<\/span> camera)<\/span>;<\/span><\/span><\/pre>\n
This is functionally identical, but it can make it possible to omit all the generic type arguments, which can help improve readability. This is possible because the C# compiler can determine the generic type arguments implicitly from the types of the variables that are passed in to the method as arguments.<\/p>\n
Note that in order for the C# compiler to be able to do this, the types of the provided variables must match the types of the Init method parameters exactly<\/strong>. So if, for example, the Player’s Init method has a parameter of type IInputManager, and you pass in a variable of type InputManager, the C# compiler will not be able to figure out the generic type arguments for the method call automatically. You can however help the compiler to get past this hurdle by casting<\/a> the variable to the exact type of the Init method parameter:<\/p>\n
var<\/span> inputManager =<\/span> Service.<\/span>GetFor<<\/span>InputManager><\/span>(<\/span>gameObject)<\/span>;<\/span><\/span>\r\ngameObject.<\/span>AddComponent(<\/span>out<\/span> Player player,<\/span> (<\/span>IInputManager)<\/span>inputManager,<\/span> camera)<\/span>;<\/span><\/span><\/pre>\n
The AddComponent extension methods can be used automatically with any components that derive from MonoBehaviour<T…>.<\/p>\n
They can also be used with any components that implement IArgs<T…><\/a> and manually receive the injected arguments using InitArgs.TryGet<\/a> in their Awake or OnEnable method.<\/p>\n
It can also be used automatically with any components that implement IInitializable<T…><\/a>, even if they don’t manually receive the injected arguments via InitArgs.TryGet. However, if they don’t<\/em> receive the arguments manually, then they will only receive them in their Init method after<\/strong><\/em> the Awake and OnEnable events. This means that it is only possible to make use of those services during and after the Start<\/a> event.<\/p>\n
Instantiate with Arguments<\/b><\/span><\/span><\/h2>\n
Init(args) also extends all components and scriptable objects with new Instantiate methods that allow passing arguments to the created instance.<\/p>\n
To clone an Object while passing Init arguments to the clone, call Instantiate on the Object you want cloned, and pass in the Init arguments to the method:<\/p>\n
prefab.<\/span>Instantiate(<\/span>inputManager,<\/span> camera)<\/span>;<\/span><\/span><\/pre>\n
New GameObject with Arguments<\/b><\/span><\/span><\/h2>\n
Init(args) also lets you create a new GameObject from scratch, attach a component to it, and pass Init arguments to the component, all in one go.<\/p>\n
To do so, use new GameObject<\/a> like you normally would, but now also include the type of the component you want attached to the GameObject as generic type argument. Then, call the Init method on the object to provide Init arguments to the attached component and finalize the whole process:<\/p>\n
var player =<\/span> new<\/span> GameObject<<\/span>Player><\/span>(<\/span>)<\/span>.<\/span>Init(<\/span>inputManager,<\/span> camera)<\/span>;<\/span><\/span><\/pre>\n
If you don’t need to pass any Init arguments to the attached component, you can finalize the process either by calling Init() with no arguments, or by assigning the object into a variable of type GameObject, or of a type matching the attached component:<\/p>\n
var<\/span> player =<\/span> new<\/span> GameObject<<\/span>Player><\/span>(<\/span>)<\/span>.<\/span>Init(<\/span>)<\/span>;\r\n\r\n<\/span><\/span>Player player =<\/span> new<\/span> GameObject<<\/span>Player><\/span>(<\/span>)<\/span>;<\/span><\/span>\r\n\r\nGameObject gameObject =<\/span> new<\/span> GameObject<<\/span>Player><\/span>(<\/span>)<\/span>;<\/span><\/span><\/pre>\n
You can also attach and initialize more than one component (up to three) at the same time, by adding generic type arguments for all the components you want attached.<\/p>\n
Then instead of calling Init on the result, you can use Init1, Init2 and Init3 to initialize the first, second and third attached components respectively:<\/p>\n
new<\/span> GameObject<<\/span>Player,<\/span> Collider><\/span>(<\/span>)<\/span>.<\/span>Init1(<\/span>inputManager,<\/span> camera,<\/span> Second.<\/span>Component)<\/span>;<\/span><\/span><\/pre>\n
Once you have provided Init arguments for all the components that need them, you can finalize the whole process by assigning the object into a variable of type GameObject, of a type matching one of the added component, or of a tuple<\/a> type matching several of the added components:<\/p>\n
Player player =<\/span> new<\/span> GameObject<<\/span>Player,<\/span> Collider><\/span>(<\/span>)<\/span>;\r\n<\/span><\/span>\r\nGameObject gameObject =<\/span> new<\/span> GameObject<<\/span>Player,<\/span> Collider><\/span>(<\/span>)<\/span>;\r\n<\/span><\/span>\r\n(<\/span>Player player,<\/span> Collider collider)<\/span> =<\/span> new<\/span> GameObject<<\/span>Player,<\/span> Collider><\/span>(<\/span>)<\/span>;<\/span><\/span><\/pre>\n
Service Arguments<\/h2>\n
If all Init arguments of a component that derives from MonoBehaviour<T…> are global<\/a> or local services<\/a>, then the component will receive all of them automatically during its initialization.<\/p>\n
In this case you do not need to need to attach an Initializer<\/a> to the component when it exists as part of a scene or a prefab.<\/p>\n
In this case you can also use the built-in Instantiate<\/a> and AddComponent<\/a> methods to create instances of the components, without needing to pass in their dependencies manually.<\/p>\n
Note that you can<\/em> still attach an Initializer or use Instantiate or AddComponent with arguments to customize the services being provided to specific client instance.<\/p>\n
For example, you could make all components use the DefaultLogger class for logging text to the Console by default, but in unit tests pass in a TestLogger using AddComponent with arguments. Or to debug the behaviour of a particular component exhibiting strange behaviour, you could temporarily attach an Initializer to it and configure it to use the more verbose DebugLogger.<\/p>\n
[<\/span>Service(<\/span>typeof<\/span>(<\/span>ILogger)<\/span>)<\/span>]<\/span><\/span>\r\nclass<\/span> DefaultLogger<\/span> :<\/span> ILogger<\/span>\r\n{<\/span><\/span>\r\n    public<\/span> void<\/span> Debug<\/span>(<\/span>string<\/span> message)<\/span> {<\/span> }<\/span><\/span>\r\n    public<\/span> void<\/span> Info(<\/span>string<\/span> message)<\/span> =<\/span>><\/span> Debug.<\/span>Log(<\/span>message)<\/span>;<\/span><\/span>\r\n    public<\/span> void<\/span> Error(<\/span>string<\/span> message)<\/span> =<\/span>><\/span> Debug.<\/span>LogError(<\/span>message)<\/span>;<\/span><\/span>\r\n}<\/span><\/span>\r\n\r\nclass<\/span> DebugLogger<\/span>\u00a0: ILogger<\/span>\r\n{<\/span><\/span>\r\n    public<\/span> void<\/span> Debug(<\/span>string<\/span> message)<\/span> =<\/span>><\/span> Debug.<\/span>Log(<\/span>message)<\/span>;<\/span><\/span>\r\n    public<\/span> void<\/span> Info(<\/span>string<\/span> message)<\/span> =<\/span>><\/span> Debug.<\/span>Log(<\/span>message)<\/span>;<\/span><\/span>\r\n    public<\/span> void<\/span> Error(<\/span>string<\/span> message)<\/span> =<\/span>><\/span> Debug.<\/span>LogError(<\/span>message)<\/span>;<\/span><\/span>\r\n}<\/span><\/span>\r\n\r\nclass<\/span> TestLogger<\/span> :<\/span> ILogger<\/span>\r\n{<\/span><\/span>\r\n    public<\/span> void<\/span> Debug<\/span>(<\/span>string<\/span> message)<\/span> {<\/span> }<\/span><\/span>\r\n    public<\/span> void<\/span> Info<\/span>(<\/span>string<\/span> message)<\/span> {<\/span> }<\/span><\/span>\r\n    public<\/span> void<\/span> Error(<\/span>string<\/span> message)<\/span> =<\/span>><\/span> Debug.<\/span>LogError(<\/span>message)<\/span>;<\/span><\/span>\r\n}<\/span><\/span><\/pre>\n
Arguments via the Inspector<\/b><\/span><\/span><\/h2>\n
You can also use the Inspector to configure the Init arguments for instances of components that derive from MonoBehaviour<T…>.<\/p>\n
Refer to the Initializer documentation<\/a> for more information on how to do this.<\/p>\n
Manually Passing Arguments in Code<\/b><\/span><\/span><\/h2>\n
It addition to all the methods listed above for passing Init arguments to components that derive from MonoBehaviour<T…> during their initialization, it is also possible pass arguments to the Init method manually.<\/p>\n
One example of a scenario where this might be useful is when using the object pool pattern<\/a>, where you might want to initialize reused instances with new Init arguments every time that they are returned from the pool.<\/span><\/p>\n
To manually pass in arguments to the Init method, simply cast the component to IInitializable<T…><\/a> and execute the Init method on it:<\/p>\n
var<\/span> initializable =<\/span> (<\/span>IInitializable<<\/span>IInputManager,<\/span> Camera><\/span>)<\/span>player;<\/span><\/span>\r\ninitializable.<\/span>Init(<\/span>inputManager,<\/span> camera)<\/span>;<\/span><\/span><\/pre>\n
Init Section<\/b><\/span><\/span><\/span><\/h2>\n
An Init section is shown by default in the Inspector for all components that derive from MonoBehaviour<T…>.<\/p>\n
\"\"<\/p>\n
Hiding the Init Section<\/h3>\n
If you want to hide the Init section for all components of a particular type, you can do so by adding the [Init] attribute<\/a> to the component’s class and setting HideInInspector<\/em> to true<\/strong>:<\/p>\n
[Init(<\/span>HideInInspector =<\/span> true<\/span>)<\/span>]\r\n<\/span>class<\/span> Client<\/span> :<\/span> MonoBehaviour<<\/span>IInputManager><\/span><\/span><\/pre>\n
Alternatively you can do the same using the Inspector by disabling the Show Init Section<\/em> item using the context menu of any component of the type in question:<\/p>\n
\"\"<\/p>\n
This can be useful in situations where Edit Mode configuration is handled via serialized fields, and providing arguments via the Init method is supposed to be optional, and only done when creating instances at runtime using AddComponent (perhaps to facilitate easy unit testing).<\/p>\n
Null Argument Guard <\/b><\/span><\/span><\/span>Icon<\/b><\/h3>\n
All components that derive from MonoBehaviour<T…> can validate that they have received all objects that they depend on via the Init method before the OnAwake event. If the Null Argument Guard is active, and a MonoBehaviour<T…> component is loaded without it having been provided it with its Init arguments, then a MissingInitArgumentsException<\/em> will be thrown.<\/p>\n
You can see information about the current state of the Null Argument Guard by mouseovering the Null Argument Guard icon in the Inspector.<\/p>\n
\"\"<\/p>\n
The Null Argument Guard is enabled in Edit Mode and at Runtime by default. If you want to adjust the Null Argument Guard used by all components of a particular type, you can do so by adding the [Init] attribute<\/a> to the component’s class and setting NullArgumentGuard to the desired value:<\/p>\n
[Init(<\/span>ArgumentGuard =<\/span> NullArgumentGuard.<\/span>None)<\/span>]\r\n<\/span>class<\/span> Client<\/span> :<\/span> MonoBehaviour<<\/span>IInputManager><\/span><\/span><\/pre>\n
Alternatively you can do the same using the Inspector by clicking the Null Argument Guard icon in the Init section of any component of that particular type, and ticking the Null Argument Guard options that you want to be enabled.<\/p>\n
\"\"<\/p>\n
You can also adjust Null Argument Guard<\/em> options individually for specific component instances by attaching an Initializer<\/a>.<\/p>\n
Add Initializer Icon<\/b><\/span><\/span><\/span><\/h3>\n
You can use the plus icon in the Init section to attach an Initializer<\/a> to the component.<\/p>\n
If no initializers exist for the component yet, pressing the icon will prompt you to generate one instead.<\/p>\n
\"\"<\/p>\n
Default Initializer<\/h3>\n
If a component has exactly one Initializer, it will be attached to the component by default when the component is attached to a GameObject in Edit Mode.<\/p>\n
You can disable this behaviour by adding the [Init] attribute to the component’s class and setting DefaultInitializer<\/em> to null<\/strong>:<\/p>\n
[Init(<\/span>DefaultInitializer =<\/span> null<\/span>)<\/span>]\r\n<\/span>class<\/span> Client<\/span> :<\/span> MonoBehaviour<<\/span>IInputManager><\/span><\/span><\/pre>\n
Alternatively you can add the [Init] attribute to the Initializer class and set DefaultInitializer<\/em> to false<\/strong>.<\/p>\n
[Init(<\/span>DefaultInitializer =<\/span> false<\/span>)<\/span>]\r\n<\/span>class<\/span> ClientInitializer<\/span> :<\/span> Initializer<<\/span>Client, IInputManager><\/span><\/span><\/pre>\n
Wait For Services<\/h2>\n
By default the initialization of components that derive from MonoBehaviour<T…> is automatically delayed until all the services that they depend on have become available.<\/p>\n
If this WaitForServices<\/em> behaviour is enabled, and any Init arguments are not available when the component is loaded, the component is disabled until all its services become available. The moment that all Init arguments have become available, they are passed to the component’s Init method, and the component is enabled, causing the Awake, OnEnable and Start methods to execute.<\/p>\n
You can disable this behaviour by adding the [Init] attribute to the component’s class and setting WaitForServices <\/em>to false<\/strong>:<\/p>\n
[Init(<\/span>WaitForServices =<\/span> false<\/span>)<\/span>]\r\n<\/span>class<\/span> Client<\/span> :<\/span> MonoBehaviour<<\/span>IInputManager><\/span><\/span><\/pre>\n
If WaitForServices behaviour is disabled, then the component will only attempt to receive its Init arguments once when it is loaded, and the component will not be disabled even if didn’t receive its Init arguments.<\/p>\n
If runtime exceptions are enabled for the Null Argument Guard, then an exception will be thrown if the component is loaded without receiving its Init arguments.<\/p>\n
Runtime State<\/h2>\n
By default the Unity editor only visualizes serialized fields in the Inspector. This can make it difficult to debug components at runtime, and gain information about whether or not they’ve acquired all the objects that they depend on.<\/p>\n
To account for this, Init(args) augments the Inspector of all components that derive from MonoBehaviour<T…> with the ability to also see the state of non-serialized members in the Inspector in Play Mode.<\/p>\n
\"\"<\/p>\n
Init Method Best Practices<\/h2>\n
It is generally speaking recommended to not use the Init method for anything else besides assigning the received arguments into member variables.<\/p>\n
Lifetime event methods like OnAwake, OnEnable and Start can then be used to execute additional logic that can make use of those services.<\/p>\n
There are a couple of reasons for this recommendation:<\/p>\n