Вы не так поняли. Разумеется можно поменять значение этой переменной. Она характеризует стартовое значение здоровья. Его можно поменять если мы хотим получить более мощьного моба например. А глобально она объявлена чтобы её можно было менять в самой Unity, и не лазить в код. Ну а вот это
Это открытый член класса, поменять значение которого можно в любом месте кода:
mobHpObject.originalHp = -300;
извините, полный моразм. Можно еще сделать так
mobHpObject.originalHp = "Охо хо я хочу делать игры";
и тогда вообще не будет работать представьте себе! Какой ужас
Хорошо я понял, я почитал про интерфейсы, они действительно решат проблему пустых методов. Но как из одного скрипта(экземпляра класса) получить ссылку на другой экземпляр другого класса(или теперь уже на интерфейс этого экземпляра) Раньше я делал это так:
MyMotor thisMotor = GetComponent<MyMotor>();
А в «вики» имеется такой пример для C#
.....
/// <summary>
/// Класс приложения.
/// В данном примере выступает как клиент контекста.
/// </summary>
public static class Program
{
/// <summary>
/// Точка входа в программу.
/// </summary>
public static void Main()
{
// Создаём контекст и инициализируем его первой стратегией.
Context context = new Context(new ConcreteStrategy1());
// Выполняем операцию контекста, которая использует первую стратегию.
context.ExecuteOperation();
// Заменяем в контексте первую стратегию второй.
context.SetStrategy(new ConcreteStrategy2());
// Выполняем операцию контекста, которая теперь использует вторую стратегию.
context.ExecuteOperation();
}
}
.......
На мой взгляд класс Program не так уж и не зависим. Он точно знает когда какую стратегию надо использовать. И если появиться новая стратегия придется менять код в void Main(). В то время как используя
MyMotor thisMotor = GetComponent<MyMotor>();
мы добьемся того что MyBehaviour сам будет выбирать первый попавшийся наследник MyMotor`а (мы наперед знаем что он один). И работать с ним.
Как я понимаю, подобной независимости в примере из вики можно добиться, сделав чтобы в классе Program происходил перебор всех имеющихся скриптов(экземпляров классов) и из них выбирался поддерживающий нужный нам интерфейс?(мы опять же знаем что он всего один на данном игровом объекте) Или я чего-то не так понял?
Про абстрактные классы вы абсолютно правы, но только в том случае, если у родительского класса совсем нет реализации методов, а это ведь не всегда так. А вот зачем вам делать полноценного монстра не видимого в списке гейм объектов мне совсем не понятно. Класс наследник должен реализовать все методы родителя. В этом весь смысл. Пустые (никак не пере объявленные методы) нужны например если мы заменили Мотор на другой Мотор, который в данной ситуации не должен реализовать прыжок, или мы захотели Мотор от одного моба повесить на другого. И самое главное, дайте мне ссылку на статью про то как пользоваться интерфейсами. Можно ли потом в переменной одного типа хранить экземпляры разных классов?
где blockType.Stone объявлена как CreateBlockIntefrace. Класс Stone реализует интерфейс CreateBlockIntefrace.
И что-то не компилится так?
Зачем вы так комментируете статью посвященную работе в Unity если никогда не работали в Unity?
извините, полный моразм. Можно еще сделать так
и тогда вообще не будет работать представьте себе! Какой ужас
сильно резко сказано
А в «вики» имеется такой пример для C#
На мой взгляд класс Program не так уж и не зависим. Он точно знает когда какую стратегию надо использовать. И если появиться новая стратегия придется менять код в void Main(). В то время как используя
мы добьемся того что MyBehaviour сам будет выбирать первый попавшийся наследник MyMotor`а (мы наперед знаем что он один). И работать с ним.
Как я понимаю, подобной независимости в примере из вики можно добиться, сделав чтобы в классе Program происходил перебор всех имеющихся скриптов(экземпляров классов) и из них выбирался поддерживающий нужный нам интерфейс?(мы опять же знаем что он всего один на данном игровом объекте) Или я чего-то не так понял?