Если переименовать сцену плагин также переименует класс после чего средства статического анализа предупредят об ошибке. В случае со строкой такого не произойдёт
Команда оформляется через интерфейс. Выражать стратегии очень удобно через анонимные методы, но когда они состоят из одного метода и ситуативны. В данном случае автор зачем-то выделил разделил логику команды и её имя. Из-за чего система стала менее очевидной (команда с одним именем и типом имеет разные действия).
Выражается это вот так
public interface ICommand
{
void Execute();
void Redo();
}
В коде автора статьи мы имеем связь Has-a, у него есть сущность «команда бота» которая содержит непосредственно действие и название. Я не вижу предпосылок для этого, как по мне логичней будет связь is-a. Команда движение есть команда бота и содержит направление движения. Ну а команда бота в свою очередь реализуют интерфейс ICommand (можно обойтись и без него).
Какие недостатки у has-a в статье:
1) Пришлось выделить фабричные методы для создания команд движения которые дублируют друг друга.
2) Redo не показана в статье но там те же пляски с дубляжом будут.
В данном случае в целом классическая дилемма: композиция против наследования. Обычно совет звучит о предпочтение композиции наследованию, но в данном случае избавления от наследования сделало систему менее стойкой и однородной.
Насчёт уродливых анонимных методов
Это просто рудемент. Вместо
new delegate(Bot bot) { /*code*/ }
Сейчас пишут
(bot) => //code
Во-втором примере ничего не изменилось. Все также непонятно какие методы оплаты доступны. Если использовать статическую типизацию, то почему бы не делать это до конца?
Я конечно извиняюсь, но может не стоит тестировать игры которые сделаны на коленке? Почему бы не протестировать действительно профессиональные продукты?
Да, мне хотелось побольше страниц
Пишите для себя
А в чём ужасность фундамента?
Спасибо за отзыв!
Взяли в работу:
-Добавим дополнительный лекции в рамках курса по Zenject и ECS
-Добавим вводный модуль по Computer Science
Выражается это вот так
В коде автора статьи мы имеем связь Has-a, у него есть сущность «команда бота» которая содержит непосредственно действие и название. Я не вижу предпосылок для этого, как по мне логичней будет связь is-a. Команда движение есть команда бота и содержит направление движения. Ну а команда бота в свою очередь реализуют интерфейс ICommand (можно обойтись и без него).
Какие недостатки у has-a в статье:
1) Пришлось выделить фабричные методы для создания команд движения которые дублируют друг друга.
2) Redo не показана в статье но там те же пляски с дубляжом будут.
В данном случае в целом классическая дилемма: композиция против наследования. Обычно совет звучит о предпочтение композиции наследованию, но в данном случае избавления от наследования сделало систему менее стойкой и однородной.
Насчёт уродливых анонимных методов
Это просто рудемент. Вместо
new delegate(Bot bot) { /*code*/ }
Сейчас пишут
(bot) => //code
Зачем создавать контейнер для делегата?
*Не имею ничего против ORM*
А, все, дочитал до нужного момента. Вопрос снят.
Во-втором примере ничего не изменилось. Все также непонятно какие методы оплаты доступны. Если использовать статическую типизацию, то почему бы не делать это до конца?