Как стать автором
Обновить

Комментарии 20

Да, но речь идёт об Assert в Zenject, который использует ==

Или оператор is null или is {}

Артисты? У вас там театральный кружок?

Художники же. Жаргон жаргоном, но есть устоявшиеся значения слов и это стоит учитывать в статье для достаточно широкого круга читателей

Совет: сдублировать issue на ветку Mathijs-Bakker, поскольку там хоть что-то происходит по сравнению с основной веткой ZJ.

Я, как человек пришедший з java-backend на unity c#, просто офигеваю с того, что сделали с c# рантаймом в unity3d. Начиная с костыльных компонентов с их event методами, заканчивая странным api с множеством статических классов.

Хочется сделать по ентерпрайзнутым понятиям, там юнит тесты, авто-тесты наклепать, а фигушки - палки будут вставлены везде :)

Юнит-тесты в играх особо не повыставляешь, потому что большая часть логики зависит от прямого контроля пользователя либо сложно эмулируема

Статик классы вполне себе нормально работают, ведь всегда легче подтянуть статик метод чем каждый раз создавать инстанс нужного класса.

Все таки энтерпрайзная жава и игровые проекты это разные вещи

Зависит от условий и проекта. На unity3d не только игры делают с минимумом сырой логики. У меня на проекте в основном юайка(динамическая, строится по внешней схеме), которую с горем пополам удалось покрыть нормально тестами, и теперь кнопки, при очередном изменении чего либо, никуда не плывут.

А статические классы в совокупности с domain reload творят чудеса в умелых руках. Чудеса с текущей памятью в умелых руках в editor mode.

Вообщем я не критикую подходы, которые используются в геймдеве(и в часности в unity3d), но они требуют некоторой адаптации(моральной, в большинстве случаев)

А можно узнать что это вы такое там делаете? Хотя бы жанр, но если можно то и подробней.
Вот за это я и не люблю Zenject, он вносит кучу неявной логики в проект, как и бай дезайн, так и вот такими вот глюками.
Тут, конечно, это косяк не самого зенжекта, а юнити, но сам факт того что пришлось лезть в кишки чужой либы, чтобы разбираться с проблемой уже отталкивает.

Что вы подразумеваете под неявной логикой?

Вызовы которые невозможно нормально отследить по стеку и зависимостям в идешке.

Все вызовы ищутся по usage, по крайней мере в rider. Так же если вы пользуетесь интерфейсами, там есть ссылки на реализации.

Что значит не нормально? Можете привести пример?

Все что инжектится через Zenject невозможно отследить по зависимостям, потому что там нет прямых вызовов. Поэтому разобраться что куда и откуда попадает практически нереально.

Так у нас всё строго типизированно, и мы видим интерфейс который нам внедрили. По использованию легко находиться место регистрации обычно, если нам это почему то важно(хотя мы программируем отталкиваясь от интерфейса большую часть времени)

Для отладки проекта важно знать, что и куда инжектится. Кроме того, так гораздо легче понимать какие части проекта зависят от других частей.
В случае с DI зависимости остаются те же самые, только теперь в неявном виде.
И не очень понял про поиск по использованию, в случае с zenject вроде как раз нельзя ничего найти таким образом.

Какая цель преследуеться? Если просто прогуляться по стеку вызовов, то ставим точку останова в редакторе и гуляем по стеку.

Поиск по использованию, мы об одном и том же? На скрине видны ссылки на usages

Для любых UnityEngine.Object (наследников MonoBehaviour, Behaviour, UnityEngine.Component или UnityEngine.Object) лучше использовать их собственный impilicit operator bool (т.е. простое приведение к bool). Там более корректная проверка на существование объекта, включающая и null-проверку, и то, что С++ объект данной C# оболочки жив.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации