А никто не говорит про скорость работы. Да и козырять ей на примере с кубиком очень уж сомнительно) Уверен, что после 5 лет разработки можно понять, что нет смысла хвастаться из-за сэкономленной миллисекунды, особенно если потратил гораздо больше времени, костыля свой фреймворк) Хотя я бы с радостью посмотрел на эти тесты Ну и для кучи можно еще VContainer протестировать, раз уж мы вдруг заговорили про скорость)
Все еще довольно сомнительно. Не понимаю кто в здравом уме между вариантами "костылить свой фреймворк ради IoC" и "посмотреть 5-минутное видео про Zenject" выберет второе. Если опять же у нас архитектура делается под "сроки, команду, бюджет и технологии", то в каком варианте этих составляющих, предпочтение сделается в пользу создания своего сервис локатора, который пытается быть похожим на di вместо использования "индустриального стандарта di-фреймворка"?) Я бы понял еще если бы шел разговор о том, что "вот Zenject не подходит, у него нет такого-то списка фичей, которые нам тут нужны", но тут мы имеем всего лишь пример с кубиком и по сути вся речь о том "как сделать тоже самое, только хуже и свое".
Их "ответственность" по сути контролируется только за счет того, что мы "считаем" контроллер главным. Что мешает нам или другому программисту в следующей фиче сделать зависимость игрока на контроллер или клавиатуру? Только очередная какая-то негласная конвенция и ориентацией на волшебные слова в названиях классов - "ну все что называется контроллер это типа важнее" Данная архитектура всего лишь упрощает доступность данных, а не решает вопрос "как мне правильно написать следующую фичу". А в плане доступности данных юнити на шаг впереди этого сервис локатора. Можно с тем же успехом просто находить зависимости через FindObjectOfType<T>
Получается какая-то мешанина из ответственностей. И игрок, и клавиатура, и контроллер движения теперь вообще сервисы. Получается "прокинь что хочешь куда хочешь и будь что будет". А сервис локатор только упрощает такое поведение. Почему бы тогда не прокинуть контроллер в игрока или ввод в игрока или игрока сразу в ввод? Раз уж они все сервисы. Весь контроль управления зиждется на том, что мы постараемся не забыть что в проекте главнее)
Статья стала бы гораздо интереснее, если бы архитектура явно решала бы какие-то задачи, а не "как двигать кубик но сделаем вид что мы архитекторы". Тогда хотя бы можно было обсуждать, хорошая она или нет и по каким причинам. Надеюсь, на курсах вы хотя бы объясняете pros & cons тех или иных подходов, а не также беспричинно строите воздушные замки...
var uiRoute = attributes[0] as UIRouteAttribute; то есть мы обязаны ставить этот атрибут первым. Это очередной неявный контракт или упрощение для статьи?
А никто не говорит про скорость работы. Да и козырять ей на примере с кубиком очень уж сомнительно) Уверен, что после 5 лет разработки можно понять, что нет смысла хвастаться из-за сэкономленной миллисекунды, особенно если потратил гораздо больше времени, костыля свой фреймворк) Хотя я бы с радостью посмотрел на эти тесты
Ну и для кучи можно еще VContainer протестировать, раз уж мы вдруг заговорили про скорость)
Все еще довольно сомнительно.
Не понимаю кто в здравом уме между вариантами "костылить свой фреймворк ради IoC" и "посмотреть 5-минутное видео про Zenject" выберет второе.
Если опять же у нас архитектура делается под "сроки, команду, бюджет и технологии", то в каком варианте этих составляющих, предпочтение сделается в пользу создания своего сервис локатора, который пытается быть похожим на di вместо использования "индустриального стандарта di-фреймворка"?)
Я бы понял еще если бы шел разговор о том, что "вот Zenject не подходит, у него нет такого-то списка фичей, которые нам тут нужны", но тут мы имеем всего лишь пример с кубиком и по сути вся речь о том "как сделать тоже самое, только хуже и свое".
По сути все о том же, что и комментом выше
Их "ответственность" по сути контролируется только за счет того, что мы "считаем" контроллер главным.
Что мешает нам или другому программисту в следующей фиче сделать зависимость игрока на контроллер или клавиатуру? Только очередная какая-то негласная конвенция и ориентацией на волшебные слова в названиях классов - "ну все что называется контроллер это типа важнее"
Данная архитектура всего лишь упрощает доступность данных, а не решает вопрос "как мне правильно написать следующую фичу". А в плане доступности данных юнити на шаг впереди этого сервис локатора. Можно с тем же успехом просто находить зависимости через FindObjectOfType<T>
Получается какая-то мешанина из ответственностей. И игрок, и клавиатура, и контроллер движения теперь вообще сервисы. Получается "прокинь что хочешь куда хочешь и будь что будет". А сервис локатор только упрощает такое поведение.
Почему бы тогда не прокинуть контроллер в игрока или ввод в игрока или игрока сразу в ввод? Раз уж они все сервисы.
Весь контроль управления зиждется на том, что мы постараемся не забыть что в проекте главнее)
Статья стала бы гораздо интереснее, если бы архитектура явно решала бы какие-то задачи, а не "как двигать кубик но сделаем вид что мы архитекторы". Тогда хотя бы можно было обсуждать, хорошая она или нет и по каким причинам.
Надеюсь, на курсах вы хотя бы объясняете pros & cons тех или иных подходов, а не также беспричинно строите воздушные замки...
var uiRoute = attributes[0] as UIRouteAttribute;то есть мы обязаны ставить этот атрибут первым. Это очередной неявный контракт или упрощение для статьи?