If you look through documentation you'll see that MonoBehaviour
constructor can present in script but it also has a lot of restrictions. For example, you cannot have any params in it. Also it's very convenient to have ability to set up component's parameters via inspector. It's especially useful when it's done by non-programmers because you don't have to change code to modify gameobject's behaviour.
Also there is a reason why Unity has so complex relations with script's constructors: it's because every gameobject and other stuff Unity does (rendering, sound, etc) in terms of memory is driven by Unity itself and scripts memory management is done by the c# garbage collector. So to avoid troubles which may occur while creating components earlier that gameobject is actually created on scene or removing gameobject from memory before it's components are removed restrictions with constructors and destructors exists. This functionality is hidden inside Unity by implementing monobehaviour methods like Start()
, Awake()
, Destroy()
.
The last thing to add is that if you work with pure c# classes in Unity (non mono inherited) you can use constructors as you wish, because you don't have this memory management problem. And if your custom fuctionality doesn't need to have any MonoBehaviour functionality (if you don't want them to be attached to any gameobject) it's more preferable to use pure c# class.