Привет!
Продолжая тему тестирования (а точнее предвосхищая ее) разберём мощный инструмент для организации кода в Unity - Assembly Definition.
❌По умолчанию все скрипты Unity компилирует в одну сборку (Assembly-CSharp.dll). Это вызывает проблемы:
* Медленная перекомпиляция (изменение любого скрипта пересобирает весь проект).
* Хаотичные зависимости (любой класс может обратиться к любому другому, даже если это не нужно).
* Сложность поддержки (в больших проектах трудно отслеживать связи между системами).
✅ Assembly Definition позволяет:
* Разделять код на независимые сборки (скрпиты одной сборки не "видят" скриптов другой, если между ними не настроена явная зависимость)
* Чётко контролировать зависимости между модулями
* Ускорять компиляцию (изменения затрагивают только нужные сборки)
⚠️ Для редакторских скриптов и тестов требуются отдельные .asmdef с настройками:
* Editor-скрипты: "Editor" в имени и включённая опция "Editor"
* Тесты: включить "Test Assemblies"
Assembly Definition и Namespace
Namespace – логическая группировка кода (защита от конфликтов имён)
Assembly Definition – физическое разделение на DLL
Можно ли обойтись без Namespace?
Технически — да, но крайне не рекомендуется тк:
* Риск конфликтов – если в разных сборках есть классы с одинаковыми именами
* Сложность навигации – без пространств имён труднее понимать структуру проекта
* Нарушение инкапсуляции – классы в глобальном пространстве видны везде
Представьте, например:
У вас есть сборка GameLogic и UI.
* В обеих есть класс Player (например, GameLogic.Player и UI.Player).
* Без namespace компилятор не поймёт, какой Player вы имеете в виду → ошибка.
С namespace конфликта нет, даже если классы в одной сборке.
Как использовать Assembly Definition
Базовая настройка:
1. Создаём .asmdef-файл
* в папке (подпапке) со скриптами: ПКМ → Create → Assembly Definition
* Даём понятное имя (например, GameLogic, UI, Network, обычно как имя подпапки или пространства имен)
2. Настраиваем зависимости, чтобы скрипты одной сборки могли работать со скриптами другой.
Например, если сборка UI использует классы из GameLogic:
* Выбираем в окне Project наш UI.asmdef
* В инспекторе в Assembly References добавляем GameLogic
3. Другие важные параметры сборки:
* Auto Referenced – разрешает доступ из стандартных сборок Unity
* Override References – ручное управление зависимостями
* No Engine References – полностью отключает доступ к Unity API (для чистого C# кода)
Структура папок
Scripts/
├── GameLogic/
│ ├── Gameplay/Player.cs (скрипт в namespace Gameplay)
│ └── GameLogic.asmdef (файл сбрки)
├── UI/
│ ├── Windows.cs (namespace UI)
│ └── UI.asmdef (зависит от GameLogic)
└── Tests/
├── Characters/HealthTest.cs (namespace Tests)
└── Tests.asmdef
✅ Рекомендации
1. Связывайте имена сборок, папок и namespace
// В сборке GameLogic.asmdef, лежащей в папке GameLogic
namespace GameLogic
{
public class Player { ... }
}
2. (Не злоупотреблять) Используйте вложенные namespace для сложных систем
namespace GameLogic.AI
{
public class EnemyBehavior { ... }
}
3. Избегайте циклических зависимостей
Сборка A не должна зависеть от B, если B уже зависит от A
4. Избегайте глобального пространства имён (классов без namespace)
Итоги
Assembly Definition даёт:
✅ Быструю компиляцию
✅ Чёткую архитектуру
✅ Лёгкий рефакторинг
✅ Защиту от случайных зависимостей
#оптимизация #архитектура