Успадкування і композиція

Модулі спираються один на одного, і жоден із них не є підкласом. Немає базового модуля, від якого можна успадкуватися, і немає ієрархії, яку можна розширити: модулі утворюють граф. Ця сторінка пояснює, що тут означає «успадкування» і які шість механізмів працюють замість нього.

Що тут означає успадкування

Цим словом називають чотири різні механізми:

RPC сутності є частиною самої сутності. Більше ніде їх немає: ні в батьківському класі, ні в спільному реєстрі. Див. Entity.
Пресет — це іменований набір, а не базовий клас. Характеристики, здібності, снаряди, генератори здобичі й об’єкти світу — це пресети entity: набори аспектів, які застосовує подання сутності (entity view). Тому вони описані на одній сторінці, Entity Presets, а не як п’ять модулів. Пресет додає аспекти, але не ставить ваш тип нижче за щось в ієрархії.
Щоб перевизначити крок платформи, досить позначити атрибутом свою заміну. Ви не успадковуєте наш крок, а оголошуєте свій. Версію обирає умова, а якщо жодна не підходить, лишається типова реалізація платформи. Див. Extensibility.
Модуль позичає інший через декоратор, який звужує або доповнює позичений інтерфейс, а реалізацію за ним можна замінити. Докладний приклад — чат усередині кімнати (room) на сторінці Groups.

Ієрархії класів модулів немає, бо дерево допускає лише гілки, а справжні функції гри їх перетинають. Підбір гравців (matchmaking) резервує місця в кімнатах. Випадання здобичі розміщує предмети через мапу. Таблицю лідерів (leaderboard) наповнює хук, який спрацьовує, коли кімната закривається.

Шість механізмів

Кожен механізм оголошують атрибутом поруч із тим, що він компонує. Це те саме декларативне правило, за яким працює все інше в SDK.

Точки монтування, як у файловій системі. Модуль монтується в корінь, об’єднуючи кілька інтерфейсів в один, або в простір імен. Якщо другий модуль претендує на зайняту точку монтування, платформа відхиляє його ще під час монтування, а не на першому виклику. Механізм описано на сторінці Під капотом.

Лексична видимість. Видимість імен іде за вкладеністю: глобальне оголошення видно всередині модуля, а локальне ніколи не просочується вгору. Що модуль надсилає — окреме питання, і його оголошують у контракті модуля: модуль знає лише ті події, які оголосив сам або які в ньому зареєстрували.

Інкапсуляція як контракт. Модуль ніколи не знає, хто його викликає і навіщо. Те, що він відкриває і що надсилає, — це весь його публічний контракт. Поведінку модуля змінюють лише видані права того, хто викликає, і більше нічого про нього.

Повторне використання через декоратор та інверсію керування. Модуль звертається до іншого через декоратор, а не лізе в нього напряму, і реалізацію за інтерфейсом можна замінити. Саме цей механізм дає змогу замінити один із наших модулів власним так, що залежні від нього модулі нічого не помітять.

Оголошення розширюють API. Оголосіть подію на групі — і з’явиться group.Send.ChatMessage(…) зі своїм контрактом. Оголосіть дані members — і з’явиться типізований гетер. Оголошення — це вхідні дані для кодогенерації. Тому версіонують саме оголошення, а не згенерований код.

Три осі адресації з одного модуля. Усі екземпляри, один екземпляр і адміністратор одного екземпляра — це три окремі API, а не один API з прапорцем. Повністю це описано на сторінці Groups.

Неявні аргументи

Усередині сутності ви ніколи не передаєте саму сутність. Отримувач, той, хто викликає, і навколишній контекст прив’язуються автоматично: усі три вже визначає те, де відбувся виклик і хто його зробив. Механізм описано на сторінці RPC.