Best use of scripts attached to game objects

Questions & Answers
1

My inclination when generating a gameobject is to give it a single script which defines all of its behavior. In many of the tutorials I’ve watched, the person will attach several scripts, each handling a different aspect of the gameobject’s behavior. Is one of these ways better from a performance standpoint, especially if there are a bunch of GameObject.GetComponent<ScriptName>() calls?

2

IF you have a bunch of GetComponent calls that you are invoking every cycle, it is generally advised to STORE the result of the call, as a member variable of the monobehavior. e.g.

MeshFilter  attachedMF;
void Start()
{
   attachedMF= GetComponent<MeshFilter>();// only calling this function ONCE
}
void Update()
{
   attachedMF.sharedMesh= exampleGenerateMeshFunction();  //using the RESULT of the GetComponent function every cycle.
}

Regarding splitting up the functionality into different classes: The main reason for this is code reusability and stability, rather than performance. If you end up wanting to create a slightly different version of your game object, you need only change/add a smaller section of code. This helps eliminate human errors, and copy/pasting, improving reliability (by not touching code that does not NEED to be changed) and decreases development time by reducing the time spent troubleshooting.