Я не знаю такого инструмента. Было бы здорово, если он появится, решилось бы много проблем.
Но наличие такого инструмента не решает проблемы, описываемые в статье. Например, не устраняет жесткую связанность между разными частями приложения.
Принципиальное отличие от стандартных событий C# в том, что стандартное событие выполняется сразу, а в моей реализации выполнение откладывается до момента, когда MonoBehaviour выполняет свой Update.
Агрументы по поводу чего?
Утверждение, что синглтоны дурной звучит для меня странно и как-то категорично. Подозреваю тут дело вкуса, но вкус обсужать не хочу, да и статье не про синглтоны.
Задайте конкретный вопрос, если что-то интересует.
Я неуверен, что там под капотом у Unity3D с многопоточностью, но возможно, что MonoBehavior инициализируются асинхронно (быть може на пулле потоков). Тогда есть вероятность, что такой вот синглтон проинициализируется дважды, трижды, стопиццотжды…
Нет, жизненый цикл MonoBehaviour гарантирует, что методы Awake и Start вызываются в конкретное время и один раз. С жизненым циклом строго и на нем логика игры строится.
Вопрос мой, собственно, в том и состоит зачем тогда его вообще наследовать от MonoBehavior? Чтобы потом вот такие костыли наворачивать? Я, видимо, профит некий упускаю из внимания.
Потому что изначально у нас есть MonoBehaviour. Если мы не будем наследовать класс от него, то класс не будет являться скриптом и не сможет быть добавлен в объект на сцену.
Помимо вышеперечисленного хардкода имен методов, ограничения по параметрам и производительности, возникает неоднозначность в случаях, когда объект, у которого вызывается SendMessage содержит в себе много разных скриптов. Нужно думать, контролировать, а вдруг еще какая-то компонента, кроме предпологаемого получателя содержит в себе метод с таким же именем, что будет в таком случае? А если наш объект содержит несколько копий одного скрипта на себе, но с разными параметрами, что будет в таком случае и как контролировать такие вызовы?
Этот факт можно легко отследить добавив в функцию инициализации синглтона проверку на то не был ли он инициализирован ранее и выводить предупреждение в дебаг, к примеру. Таким образом можно немного обезопасить себя от ошибок невнимательности.
Я может не увидел по тексту… но зачем синглтон скрещивать с компонентом (MonoBehavior)?
Потому что в статье рассказывается о способак взаимодействия именно скриптов Unity (наследников MonoBehviour), которые живут в жизненном цикле сцены и могут использовать в своей логике факты вызовов таких функций как (Awake, Start, Update и множество других).
Но наличие такого инструмента не решает проблемы, описываемые в статье. Например, не устраняет жесткую связанность между разными частями приложения.
Утверждение, что синглтоны дурной звучит для меня странно и как-то категорично. Подозреваю тут дело вкуса, но вкус обсужать не хочу, да и статье не про синглтоны.
Задайте конкретный вопрос, если что-то интересует.
Ступайте с миром!
Нет, жизненый цикл MonoBehaviour гарантирует, что методы Awake и Start вызываются в конкретное время и один раз. С жизненым циклом строго и на нем логика игры строится.
Потому что изначально у нас есть MonoBehaviour. Если мы не будем наследовать класс от него, то класс не будет являться скриптом и не сможет быть добавлен в объект на сцену.
Потому что в статье рассказывается о способак взаимодействия именно скриптов Unity (наследников MonoBehviour), которые живут в жизненном цикле сцены и могут использовать в своей логике факты вызовов таких функций как (Awake, Start, Update и множество других).