Component/Script that represent the object?

Hi!

I’m interested in your opinions regarding having a “main” script/monobehaviour that represent the object. For example:

If I have a Cube in the scene that have different components and monobehaviours (maybe “Moveable” and “Clickable”). Sometimes some functionality wont fit into (or does not make sense to have) a own component.

Is it bad practice to have a “main” component/script on the object, for example “Human”, “Player” or “Cube”. The system I have right now is kind of a traditional “inheritance style” and composition-style hybrid… To clearify: I keep as little as possible in the “main” script/monobehaviour.

The syntax kinda gets weird:

GameObject player (....gets the game object....)
Player p  = player.GetComponent<Player>();

I don’t see anything wrong with the practice, nor with the syntax.
It’s very common to get a GameObject reference for the purpose of getting a component on that GameObject.

Depending on how you’re getting the GameObject reference, you can skip that all together and just get the component directly.
For example, if you were assigning the GameObject reference in the inspector, you could replace the GameObject type with the Player type and drag the Player script into the inspector instead.

1 Like