Другой класс может наследоваться от CustomBehaviour. Поскольку в игровой логике, компоненты так или иначе MonoBehaviour, ничто не мешает сделать
public class ChildClass: MyClass {}
public class MyClass: CustomBehaviour {}
В целом понятно, это из разряда UniRx, без «ста грамм» не разобраться и придумать адекватное применение еще сложнее, надо разбираться и долго. Спасибо за наводку, посмотрим этот Entitas.
Ну во-первых, у меня объекты игровой логики не инициализируются в конструкторах, практически никогда. Во вторых, иньекции в конструктор или в свойство так или иначе требуют ссылки на интерфейс, что в моем понятии может и менее жесткая связь, чем прямая ссылка на экземпляр класса, но и не мягкая связь тоже. Я предпочитаю, чтобы компоненты вообще ничего не знали, ни через интерфейсы ни каким либо другим способом друг о друге, т.е. абсолютная независимость. Может конечно я заблуждаюсь, но мой линчый опыт говорит об обратном. К сожалению, я больших проектов мобильных аля Clash of Clans не делал, поэтому не могу сказать как описанные в статье системы поведут себя там, равно как я не знаю применяется ли там DI, в том же смысле, что и система уведомлений.
В целом, если бы я например писал не игровую логику (реализация игрового процесса), а некую большую обособленную систему, которая использовалась бы в ней, и в этой системе нужно было бы использовать внешние какие-то вещи, тогда да, DI и сам принцип IoC имел бы смысл. В некотором смысле в тех проектах, в которых я участвовал, эти принципы применялись при подключении тех же платежных API для мобильный проектов.
Да, есть системы разные, для одних проектов подходят одни для других другие. Но вот в данном случае, DamageDealSystem как-то должно узнать что появился объект с компонентом DamageComponent и HealthComponent.
DI и IoC это паттерны, которые я считаю применять можно, но не шибко удобно в объектно-компонентном подходе, который я стараюсь использовать при разработке игр на Unity3D.
Пробовали, это более высокий уровень нежели то, что описано в статье и помимо прочего UniRx он про асинхронное программирование, а там надо несколько все по другому думать в плане архитектуры и т.п.
public class ChildClass: MyClass {}
public class MyClass: CustomBehaviour {}
В целом, если бы я например писал не игровую логику (реализация игрового процесса), а некую большую обособленную систему, которая использовалась бы в ней, и в этой системе нужно было бы использовать внешние какие-то вещи, тогда да, DI и сам принцип IoC имел бы смысл. В некотором смысле в тех проектах, в которых я участвовал, эти принципы применялись при подключении тех же платежных API для мобильный проектов.