Почему мне нужно объявить переменную с тем же именем класса и сценария?

Question

public class CanvasManager : MonoBehaviour
{
    public static CanvasManager Instance; // = lobby  
    [SerializeField]
    private LobbyFunction _lobbyFunction;
    public  LobbyFunction LobbyFunction
    {
        get { return _lobbyFunction; }
    }
    ...

ниже приведена одна из ссылок

private void Start()
{
    GameObject lobbyCanvasGO = CanvasManager.Instance.LobbyFunction.gameObject;
    ...

Я сбит с толку, что необходимо иметь то же имя canvasmanager, что и объявленное, и почему нет ошибки, когда я говорю CanvasManager.Instance.LobbyFunction, меня это смутило, поскольку LobbyFunction принадлежит CanvasManager, а не Instance.

Наконец, иногда

private LobbyFunction _lobbyFunction;
private   LobbyFunction LobbyFunction
{
    get { return _lobbyFunction; }
}

Иногда

private LobbyFunction _lobbyFunction;
public  LobbyFunction LobbyFunction
{
    get { return _lobbyFunction; }
}

Спасибо за ваше терпение, прочитав это, и ваша помощь будет принята с благодарностью, спасибо!

Answer 1

Ваш класс называется CanvasManager, но вы не можете получить к нему статический доступ сразу. Вы создали переменную-член stati c в CanvasManager, которая содержит ссылку на CanvasManager. Это называется singleton pattern .

. Вы можете получить доступ только к элементам stati c без экземпляра класса. Но в случае синглетов вы создаете один экземпляр класса (обычно назначаемый в Start() или в getInstance() (ленивый) после проверки, существует ли он), к которому затем можно получить статический доступ через «Экземпляр».

Теперь Instance - это переменная stati c, содержащая ссылку на один экземпляр CanvasManager. Таким образом, вы можете получить доступ к незаполненным c членам и функциям CanvasManager, если получите доступ к «Экземпляру».

Подумайте об этом так:

CanvasManager local_instance = new CanvasManager();
local_instance.non_static_member = value; // this works

CanvasManager.static_member = value; // this works
CanvasManager.non_static_member = value; // won't work.

И теперь один шаг далее, вы получаете доступ к экземпляру через CanvasManager.Instance.*

CanvasManager.Instance.non_static_member = value; // works!

Объяснение состояний c против не-состояний c:

нормальных переменных :

Переменным нужна память. Поэтому обычно вы создаете 5 экземпляров CanvasManager, и каждый экземпляр может иметь разные значения. Потому что каждый экземпляр резервирует память для каждой переменной. Но если вы хотите изменить один, вам нужно явно поговорить с этим экземпляром. Вы можете управлять ими в списке или с помощью нескольких переменных в коде, таких как manager1, manager2 ...

Думайте об этом как о книгах, где каждая копия может быть изменена (записать в нее примечания)

stati c переменные

Если вы создаете переменную stati c, память резервируется один раз для класса. Затем вы можете напрямую получить / установить эту переменную stati c из любой точки кода без необходимости ссылки на экземпляр.

Думайте об этом как о сетевом блоге, где изменения применяются ко всем, доступны везде. Текст существует один раз в базе данных блога.

Одиночки:

Если вам нужен только один CanvasManager, а не 5, вы можете присоединить его к любому GameObject. и получить к нему доступ. Но каждому другому сценарию нужна ссылка, например public CanvasManager my_manager, которую нужно назначить в инспекторе. В качестве альтернативы вы можете использовать

GameObject.Find("CanvasManagerObject").getComponent<CanvasManager>()

в каждом скрипте ... Если бы только был лучший способ получить доступ к этому CanvasManager из любого места ...

Шаблон синглтона позволяет вам получить ссылку на один нестандартный c экземпляр CanvasManager, в то время как ему даже не нужен объект GameObject, к которому он может присоединиться.

Наименование Вы говорите о том, что «оно должно иметь одинаковое имя» - это неправда. Вы можете назвать экземпляр как угодно. CanvasManager.MyCustomlyNamedInstance тоже подойдет. Но MyCustomlyNamedInstance должна быть переменной stati c в классе CanvasManager или любом другом классе. У вас может быть GameManager, который управляет вашими экземплярами, так что GameManager.MyCanvasManagerInstance тоже будет работать.