А сущности у нас обычно состоят из многих компонентов... тот же самый игрок, или NPC
Иногда встречаю высказывания, что всю логику хорошо бы делить еще и по MVC/MVP
никогда не ясно насколько качественный код предоставляется в качестве решения моей проблемыЗабей на "качественный код". Писать говнокод ты будешь в любом случае, этого не избежать. Избежать "некачественного кода" при обучении невозможно.
Посоветуйте с чего начать и к чему продвигаться
var physicsResults = new NativeArray<RaycastHit>(Entities.Length, Allocator.TempJob);
var physicsHandle = SpherecastCommand.ScheduleBatch(physics.Casts, physicsResults, 1, 1);
physicsHandle.Complete();
ситуация слишком простая, чтобы подход себя оправдал.
После этого мне начинает казаться, будто мы говорим об одном и том же, но разными словами.
чистая архитектура у меня есть, но что-то я не помню там рекомендаций накидывать повсюду мелкие классы.
Я тебя так понял, будто мы должны по-умолчанию делать все поля публичными и переводить их в приватные, если поняли, что они должны быть приватными.
А дальше разработчика порвало, несите нового.
Если обратить внимание, лично я ни разу не аппелтровал к защите и безопасности, ни в комментах, ни в ответах.
С публичным полем health разработчик (не обязательно другой), может в другом месте кода напрямую изменять его значение, что приведёт к очевидному багу - какой-то персонаж в каких-то условиях будет просто бессмертным.
Предлагаю тебе ещё посмотреть на весь веб
Реальная история?
К сожалению (или к счастью) у меня на полке таких книг нет. Пример будет?
А зачем эта дополнительная ценность нужна для принятия решения о закрытии полей?
Сделаем всё приватным.
Сделать публичное поле приватным - breaking changes.
Как такое ограничения сделать при помощи публичных полей? Да никак.
Ты нейросеть или просто прикидываешься ей?