Unity: Use Inherited properties component or Inspector Injected components-CodePudding

I'm new to Unity but have development experience. I'd like to know whether I should be using the inherited properties in my MonoBehaviour scripts, or if I should be injecting everything from the inspector instead.

I'm following a tutorial that has suggested writing some code like this:

public class BirdScript : MonoBehaviour
{

    public Rigidbody2D myRigidbody;

So that the Inspector can inject the component's Rigidbody2D into it:

When playing with the code, I noticed that MonoBehaviour extends Component and I can do this.rigidbody2D instead. I got told off by Intellisense for this, but it suggested instead using: GetComponent<Rigidbody2D>().

Using this, instead of my code reading:

void Update() 
{ 
    myRigidbody.velocity = Vector2.up * 10; 
}

I can write:

void Update()
{
    GetComponent<Rigidbody2D>().velocity = Vector2.up * 10;
}

But which is better? I'm thinking GetComponent<Rigidbody2D>() because it makes sure that I'm directly referencing the current rigid body that my script is attached to, instead of requiring me to apply things in the Inspector, but maybe this is too inflexible for Unity? In general, the style seems more lenient towards making things public instead of private for the sake of the Inspector.

Any advice on some best practices I can use to make these kinds of decisions?

CodePudding user response：

Assigning a reference through the inspector or referencing an attached component using GetComponent<T> are both valid options. Although I would generally avoid calling GetComponent<Rigidbody2D>() in the Update() function since it's expensive, and instead cache the reference in Start().

The Start method is called after all initialization methods have been completed, so it is safe to use GetComponent in this method to access fully initialized components.

private Rigidbody _rigidbody;

private void Start() {
    _rigidbody = GetComponent<Rigidbody2D>();
}

Referencing Components

One potential downside of referencing components through drag-and-drop in the Unity Inspector is that managing your project's dependencies can be challenging. This is because drag-and-drop references can create implicit dependencies that are not immediately obvious from looking at the code. This can make it difficult to understand how different parts of your project are interconnected and can make it harder to refactor or modify your code in the future. As such, .GetComponent provides an alternative in-code solution.

GameObject.GetComponent

One potential downside of using GetComponent to create component references in Unity is that it can make your code more difficult to read and understand because GetComponent calls could be spread throughout your code. In contrast, drag-and-drop references in the Unity Inspector can be easily seen and understood by looking at the inspector window for a particular game object.

Another potential downside of using GetComponent is that it can make your code more fragile. This is because GetComponent calls rely on the components attached to the game object at runtime and will throw an error if the required component is not present. However, this could be alleviated using the RequireComponent attribute, making said components dependent.

In contrast, drag-and-drop references in the Unity Inspector are checked at edit time and will only allow you to reference components attached to the game object. This can help to prevent runtime errors in your code.

Overall, whether to use GetComponent or drag-and-drop references in the Unity Inspector will depend on your personal preferences and the specific needs of your project. Both approaches have advantages and disadvantages, and the best approach for your project depends on the specific circumstances.