Search Unity

Get Component to the Script vs Instance of the Script itself

Discussion in 'Scripting' started by Yunnan, Jan 30, 2015.

  1. Yunnan

    Yunnan

    Joined:
    Jan 9, 2015
    Posts:
    10
    In order to get variable(s), function(s) in another class, I have known 2 ways of doing this. First, is to use Get Component to the Script that we want to get the variable(s), function(s) into. Second, is to use Instance of the Script itself.

    So I have made the following code:

    First case: Get Component to the Script itself

    Code (CSharp):
    1. public class Manager : MonoBehaviour
    2. {
    3.     private AnotherManager _anotherManager;
    4.  
    5.     private void Awake()
    6.     {
    7.         _anotherManager = GameObject.Find("Managers").GetComponent<AnotherManager>();
    8.     }
    9.  
    10.     private void Start()
    11.     {
    12.         _anotherManager.myIntVariable = 10;
    13.  
    14.         _anotherManager.MyFunction();
    15.     }
    16. }
    17.  
    18. public class AnotherManager : MonoBehaviour
    19. {
    20.     public int myIntVariable;
    21.  
    22.     public void MyFunction()
    23.     {
    24.  
    25.     }
    26. }
    Second case: Use Instance of the Script itself

    Code (CSharp):
    1. public class Manager : MonoBehaviour
    2. {
    3.     private void Start()
    4.     {
    5.         AnotherManager.instance.myIntVariable = 10;
    6.  
    7.         AnotherManager.instance.MyFunction();
    8.     }
    9. }
    10.  
    11. public class AnotherManager : MonoBehaviour
    12. {
    13.     public static AnotherManager instance;
    14.  
    15.     public int myIntVariable;
    16.  
    17.     private void Awake()
    18.     {
    19.         instance = this;
    20.     }
    21.  
    22.     public void MyFunction()
    23.     {
    24.  
    25.     }
    26. }


    My question is: Is there any difference between those cases? In terms of good practice of coding for programmer or performance or it is just a matter of programmer's perspective or whatever else?

    Thanks
     
  2. Polymorphik

    Polymorphik

    Joined:
    Jul 25, 2014
    Posts:
    599
    Well the former will use up more CPU by having to first find the GameObject by name then also find the component. Where the latter already has the instance cached and all you are doing is accessing the instance of it by a public static variable.

    Depending which way you go about things depends what it is you want to accomplish/the encapsulation of the data that the script is supposed to protect. Globalizing an instance is okay, if you want any class to be able to access it, if this is not what you are trying to do you might want to rethink your design pattern here.

    There is no set in stone answer because it really just depends on your implementation.
     
  3. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    With no other infomation available I would say do the first and not the second. Statics are to be avoided unless you have a good reason for them.

    (There are good reasons, just none in the OP)
     
  4. Korno

    Korno

    Joined:
    Oct 26, 2014
    Posts:
    518
    If you only have one instance of that script in the entire scene then statics are ok. Managers work well this way. For example I have a director class which is responsible for playing sounds when things happen (listening to events that game objects make) now it doesnt make sense to have more than one instance of this in a scene. So I have:

    Code (CSharp):
    1. public class Director : MonoBehaviour
    2. {
    3.     public static Director Current;
    4.     private void Awake()
    5.     {
    6. if(current != null) throw new Exception("There must only be one director component in the scene");
    7.         current = this;
    8.     }
    9. }
     
  5. Dantus

    Dantus

    Joined:
    Oct 21, 2009
    Posts:
    5,667
    Avoiding a GameObject.Find with a string based search sounds like a good reason to do so in my opinion. Though, a reusable Manager class might be more appropriate.