Поддержу коллегу. Иконка, при беглом осмотре, производит странное впечатление. Я с большим уважением отношусь к Вашему продукту, однако из-за сочетания рисованного персонажа на переднем плане и 3D бэкграунда иконка выглядит, как бы это сказать, не очень профессионально? При внимательном рассмотрении это ощущение проходит, но первый взгляд всегда очень важен
StrangeIOC использовать можно, но аккуратнее с командами. При большом количестве команд получаем просадку по производительности. У нас используется на одном проекте, там стараемся обходиться обычными эвентами C#.
Свой контейнер не профайлили — как то не понадобилось. На проектах, в которых он используется проблем с производительностью нет.
Не уверен, что понял правильно. Мы используем интерфейсы вместо абстрактных классов — их можно реализовывать сколько угодно. Про то что скрестить DI с Unity непросто — согласен. Я постепенно переосмысливаю свой подход и постараюсь в скором времени выкатить более адаптированную версию
К сожалению да, только через BuildUp. Соответственно если это объекты в дереве сцены, то находим их и инжектим в них зависимости на старте локации. Если это динамически создаваемые объекты, например инстанцированные префабы, то нужна фабрика. Фабрика может иметь зависимость от самого контейнера. А для это нужно зарегать контейнер в нем самом ))
Соглашусь с коллегой kekekeks. DI-контейнер — это всего лишь переменная в вашей программе. Делать ли ее глобальной и доступной отовсюду — ваше личное дело. Вот например:
public void Start()
{
var container = CreateContainer();
_gameMain = container.Resolve<GameMain>();
}
Здесь контейнер не является глобальной переменной и создается только лишь для того, чтобы создать и нужным образом сконфигурировать объект _gameMain.
Если у вас в конструкторе будет больше (пускай) десятка зависимостей — это показывает, что у вас что-то не так с дизайном и нарушение SRP, что опять же заслуга constructor injection
Не только constructor injection, извините )) При properties injection это тоже очень хорошо заметно
Спасибо за доброе слово! Конечно можно написать про best practices, которые из всего этого вытекают, но похоже, темой заинтересовались не многие.
Я подумаю, чем еще нетривиальным могу поделиться с хабрсообществом. Есть мысли прикрутить ко всему этому AOP ;)
Про ограничения на constructor injection я уже написал выше, в случае Unity3D (не путать с Unity Application Block) это не всегда возможно. А в остальном соглашусь.
А вот вопрос про то, насколько хорошо видны все зависимости при этом. Скажите, а нет ли проблем с тем, чтобы отличить зависимости (которые вы наверное копируете в read-only поля) от других read-only полей? Или таких не бывает, и все что read-only — это стопудово зависимость?
Насчет мартышкиного труда — это не самая большая проблема, коллега. Например Resharper может генерировать конструкторы за Вас. Заводим поля в классе, а затем жмякаем на кнопочку «Создать конструктор». Решарпер предложит выбрать, какие члены класса мы хотим инициализировать в конструкторе, и генерирует конструктор с соответствующими входными параметрами и присваиваниями.
К сожалению, я не читал книгу, которую рекомендует коллега kekekeks. И могу только предлагать, какие там приведены доводы «за» и «против». Наверное, иньекции через конструктор более безопасны — конструктор можно вызвать только один раз, а в свойства какой-нибудь нехороший код может писать что-угодно и когда угодно.
Однако мне всегда было интересно, что произойдет, если у класса несколько конструкторов? Какой из них контейнер выберет? А как быть, если объект класса создается внешней системой, которая не рассчитана на применение DI-контейнера? Например, если объект класса десериализуется каким-то внешним кодом, как это происходит в случае скриптов в Unity?
А в остальном — полностью с Вами согласен :)
К сожалению, иньекции через конструктор невозможны для объектов, создаваемых Unity, т.е. для всех производных от MonoBehaviour. Можно конечно инжектить в них через методы, но тогда это не read-only поля. И эти поля надо как-то отличать от других полей, явно выделять в коде класса.
А атрибуты на свойствах делают это замечательно. Ну и плюс у вас есть полный контроль над тем, в какие свойства инжектится, а какие — просто свойства
Вы попробуйте на практике, вдруг Вам понравится? ))
Интересной была одна особенность всех решений — все… абсолютно все смотрели на задачу, следуя буква к букве её описанию в начале поста: сетка, по ней пробегает волна…
Мне кажется, что это абсолютно естественно — предлагать решение в терминах предметной области. Представьте пожалуйста такую ситуацию: вы пришли работать, ну скажем, в банк и вам передали на поддержку код вашего предшественника. Вы обрадуетесь, обнаружив внутри вместо абстракций «клиент», «счет», «ежемесячная выплата» и т.д. нейросеть? При этом все работает супер )))
Использование языка предметной области при разработке дает шанс, что код можно будет развивать и поддерживать. Не гарантирует, конечно )) Ведь вы же сможете нового сотрудника обучить специфике вашей предметной области, не так ли?
Мне кажется коллега Dimmerg не имел ввиду, что не нужно развиваться вовсе. Ученье — свет, про это никто не спорит. Вопрос именно в том, нужно ли источать этот свет в сообщество. Большинство моих знакомых программистов — интроверты и мало нуждаются в онлайновой жизни. При этом они поддерживают свой профессиональный уровень на должном уровне
Свой контейнер не профайлили — как то не понадобилось. На проектах, в которых он используется проблем с производительностью нет.
Здесь контейнер не является глобальной переменной и создается только лишь для того, чтобы создать и нужным образом сконфигурировать объект _gameMain.
И кому принадлежит цитата?
Не только constructor injection, извините )) При properties injection это тоже очень хорошо заметно
Я подумаю, чем еще нетривиальным могу поделиться с хабрсообществом. Есть мысли прикрутить ко всему этому AOP ;)
А вот вопрос про то, насколько хорошо видны все зависимости при этом. Скажите, а нет ли проблем с тем, чтобы отличить зависимости (которые вы наверное копируете в read-only поля) от других read-only полей? Или таких не бывает, и все что read-only — это стопудово зависимость?
К сожалению, я не читал книгу, которую рекомендует коллега kekekeks. И могу только предлагать, какие там приведены доводы «за» и «против». Наверное, иньекции через конструктор более безопасны — конструктор можно вызвать только один раз, а в свойства какой-нибудь нехороший код может писать что-угодно и когда угодно.
Однако мне всегда было интересно, что произойдет, если у класса несколько конструкторов? Какой из них контейнер выберет? А как быть, если объект класса создается внешней системой, которая не рассчитана на применение DI-контейнера? Например, если объект класса десериализуется каким-то внешним кодом, как это происходит в случае скриптов в Unity?
А в остальном — полностью с Вами согласен :)
А атрибуты на свойствах делают это замечательно. Ну и плюс у вас есть полный контроль над тем, в какие свойства инжектится, а какие — просто свойства
Вы попробуйте на практике, вдруг Вам понравится? ))
Мне кажется, что это абсолютно естественно — предлагать решение в терминах предметной области. Представьте пожалуйста такую ситуацию: вы пришли работать, ну скажем, в банк и вам передали на поддержку код вашего предшественника. Вы обрадуетесь, обнаружив внутри вместо абстракций «клиент», «счет», «ежемесячная выплата» и т.д. нейросеть? При этом все работает супер )))
Использование языка предметной области при разработке дает шанс, что код можно будет развивать и поддерживать. Не гарантирует, конечно )) Ведь вы же сможете нового сотрудника обучить специфике вашей предметной области, не так ли?