Comments 5
Сразу вопрос: зачем нам nullable-типы в проекте, что мы хотим получить? В статье мотивация не раскрыта, обозначу сам -- чтобы получать предупреждение в редакторе о потенциальных NRE в коде.
Для этого существует Rider и аннотации, в частности [CanBeNull]. А здесь автор предлагает каждый класс пачкать директивой, так еще и по всему коду сборки бегать расставлять обратный костыль-директиву, в случае сборок разумеется.
Отдельно отмечу что единственный профит от сборок (AssemblyDefenition) - ускорение перекомпиляции скриптов проекта. Когда их добавляют на геймплейные модули и системы - больше проблем от распутывания референсов, чем выигрыша от реюза кода. Все примеры обожания асм-дефов которые я наблюдал начинались из-за неадекватно большого желания сэкономить время (= жадности) и/или большой глупости и заканчивались плачевно для проекта. Проекты были ГК и матч3, с попыткой выделения SDK и "собственного" фреймворка, чтоб конвеерно шлёпать прототипы. Конец немного предсказуем. В больших и хардкорных проектах такого недуга не наблюдал. Поэтому asmdef-ы использую только для того кода, который никогда не меняется -- сторонние библиотеки и фреймворки (если еще не) и базовые UI-компоненты (окна/кнопки для префабов, кладу в отдельную папку и сборку).
Отдельно поворчу, что:
1. Неизменяемые данные лучше делать struct или хотя бы record. Судя по [Serializable] ,UserResponse - это все таки данные, одноразовые, зачем они class?
2. Их открытые члены -- свойствами, а не полями. Есть еще атрибут [field:], если вдруг для Инспектора захочется не городить свойства+поля.
3. Пул также совершенно зря наследуется от MonoBehaviour. Монобехи это бридж между C#-классами сервисов и миром Unity - объектами сцены. Не могу представить какие ссылки со сцены нужны пулу, ну если он только не спавнер одновременно.
Cпс, за комменты
по поводу мотивиции, как раз указанн в самом вверху статьи 'Ключевые особенности' -
Поиск потенциальных мест с
NullReference
c 1-3 согласен, но данной контекс лишь изолированный пример, он служит только для показа nullable аннотаций
по поводу обмазывания аннотация никто это делать не предлагает, это лишь примеры как включить статический анализ в конкретных местах,
никто не запрещает сделать один глобальный конфиг nullable или все доменную область Game.asmdef отметить данной аннотацией
для этого их и сделали необязательным, чтобы можно было потихоньку включить анализ лишь для отдельных частей,
в конретной практике скажу, что это удобно даже больше для UPM packages, где юзер получает внешнее API и ему явно указывается контракт
Для меня это просто банально выглядиь читаемый, чем подстановки [CanBeNull] аттрибуты, особенно в случае с сигнатурами.
Это стоит воспринимать как еще один помощник статическу анализаторому, а не панацею от всех бед, т.к даже в офф. гите MS, можно найти довольно уникальный кейсы когда анализатор даже не заметит NullRef, т.к с новыми версиями .Net они дорабатывают ее.
конкретно по 2 пункту, field-property
Стандартный Unity JsonUtility не умел сериализовать свойства и при вызове метода JsonUtility.ToJson результатом был пустой json.
Отпишите, если вдруг в какой-то версиях это добавили,
данный формат в Unity поддерживала только зависимость на Newtonsoft.Json
в случае использования JsonUtility через свойства с [field: SerializeField],
получится json c backing fields вида:{<Id>"k__BackingField":30518,<Name>"k__BackingField":"mesh"}
что явно может ломать backend, если на нем не используется явнай парсер от Unity
Newtonsoft.Json же при сериализации property, имеет стандартный формат вида:{"Id":30518,"Name":"mesh"}
Включаем Nullable reference types в Unity за несколько минут