Комментарии 20
Вместо == лучше использовать ReferenceEquals(animator, null)
Артисты? У вас там театральный кружок?
Жаргон же. Не называть же их "Деятель искусств". https://en.wikipedia.org/wiki/Artist
Совет: сдублировать issue на ветку Mathijs-Bakker, поскольку там хоть что-то происходит по сравнению с основной веткой ZJ.
Я, как человек пришедший з java-backend на unity c#, просто офигеваю с того, что сделали с c# рантаймом в unity3d. Начиная с костыльных компонентов с их event методами, заканчивая странным api с множеством статических классов.
Хочется сделать по ентерпрайзнутым понятиям, там юнит тесты, авто-тесты наклепать, а фигушки - палки будут вставлены везде :)
Статик классы вполне себе нормально работают, ведь всегда легче подтянуть статик метод чем каждый раз создавать инстанс нужного класса.
Все таки энтерпрайзная жава и игровые проекты это разные вещи
Зависит от условий и проекта. На unity3d не только игры делают с минимумом сырой логики. У меня на проекте в основном юайка(динамическая, строится по внешней схеме), которую с горем пополам удалось покрыть нормально тестами, и теперь кнопки, при очередном изменении чего либо, никуда не плывут.
А статические классы в совокупности с domain reload творят чудеса в умелых руках. Чудеса с текущей памятью в умелых руках в editor mode.
Вообщем я не критикую подходы, которые используются в геймдеве(и в часности в unity3d), но они требуют некоторой адаптации(моральной, в большинстве случаев)
Тут, конечно, это косяк не самого зенжекта, а юнити, но сам факт того что пришлось лезть в кишки чужой либы, чтобы разбираться с проблемой уже отталкивает.
Что вы подразумеваете под неявной логикой?
Все вызовы ищутся по usage, по крайней мере в rider. Так же если вы пользуетесь интерфейсами, там есть ссылки на реализации.
Что значит не нормально? Можете привести пример?
Так у нас всё строго типизированно, и мы видим интерфейс который нам внедрили. По использованию легко находиться место регистрации обычно, если нам это почему то важно(хотя мы программируем отталкиваясь от интерфейса большую часть времени)
В случае с DI зависимости остаются те же самые, только теперь в неявном виде.
И не очень понял про поиск по использованию, в случае с zenject вроде как раз нельзя ничего найти таким образом.
Для любых UnityEngine.Object (наследников MonoBehaviour, Behaviour, UnityEngine.Component или UnityEngine.Object) лучше использовать их собственный impilicit operator bool (т.е. простое приведение к bool). Там более корректная проверка на существование объекта, включающая и null-проверку, и то, что С++ объект данной C# оболочки жив.
Подводные камни Zenject или тайный мир Unity GetComponent