Кто как решает проблемы связности кода и чрезмерного раздувания класса

главного charactera или pawn'a? Вот даже если используем мы компоненты и скажем вынесли жизнь выносливость и пр в CharacteristicsComponent. Но потом все равно другие экторы обращаются к этому чарактеру и хотят узнать его жизнь. В каждом куске кода делать что-то типа
auto CharComp = Cast<UCharactericticsComponent>(Character->GetComponentByClass(UCharactericticsComponent::StaticClass()))
if (CharComp)
{
CharComp->GetHealth()
}
не очень-то удобно. Хочется просто сделать Character->GetLife(), но тогда Character->GetLife() вызывает CharactericticsComponent->GetLife() и фактически вместо упрощения мы получаем усложнение, т.к. функция GetLife() описана и в игроке и в компоненте игрока. Да, мы часть функций все-же инкапсулируем в чарактер компоненте, но на практике выходит не так уж и много.
Но т.к. компонентов дохрена, то каждый из них дублирует важные функции в чарактере, а иногда не просто дублирует, а реализует (т.к. компоненты не знают друг о друге, а чарактер знает о своих компонентах и поэтому знает, как, например, revivecomponent'у получить сведения о здоровье героя из characteristics компонента). В итоге получается адски сложный класс, который знает всё обо всём, который жестко связан с его компонентами и просто добавить/удалить компонент из чарактера (как того требует хорошая модульная архитектура и OpenClosed принцип) становится невозможным. Короче, чарактер нарушает принципы правильной архитектуры приложений и как это победить я пока что не придумал.

лучше не юзать FindComponentByClass, очень дорогая операция

Да, а чем лучше той записи?

https://github.com/PushkinStudio/PsData - коротко см. UFooCharacterData Health как синтетический пример. Кому надо - будут общаться именно с датой, а не с классом керектера в котором логика и так далее.

всё также ничего непонятно. Слова UFooCharacterData и Health встречаются только в readme. Health встречается только в момент объявления... Ну и вопрос был больше про логику, а не про дату. Обычно в карактерах слишком много логики запутанной и связной и поддерживать такой класс адски сложно.

Вот как раз все в первую очередь про дату :) Никому не надо лезть в персонажа и что-то в нем вызывать, чтобы получить хелсы. И что там внутри для этого вызовется и где будет дублироваться - тоже десятый вопрос. Ты выводишь те же хелсы в дату персонажа, далее именно в нее ходят все, кому нужно. Включая даже самого персонажа. Тебе нужны хелсы на хаде? Ты берешь их из даты. Нужны внутри персонажа при проверке хелсов? Ты берешь их из даты. Хелсами занимается какой-то из сабкомпонентов внутри компонента "мое здоровье" у персонажа? Да на здоровье - он все равно работает с датой. Все стейтовые данные такого рода (хелсы, инвентарь, количество патронов, состояние падение/бег/полет, наложенные эффекты заклинаний и их свойства - это все легко описывается таким образом). По итогу у тебя нет зависимости на жирный класс персонажа, а есть зависимость на дата-модель, причем в виде отдельных кусков (менеджеру инвентаря не нужен весь персонаж как зависимость, ему нужна только дата-инвентаря). Сам класс персонажа ты можешь делить на компоненты по мере их необходимости, и только необходимые внешние функции управления оставить в качестве публичного API класса (или более - реализовать через интерфейс).

Привет! А каким образом осуществляется соответствие между объектами и их данными?

Я после того обсуждения стал все практически все auto конвертировать с помощью райдера в полный тип, исключая всякие итераторы в некоторых случаях, когда действительно много текста будет и будет путать.

Разделяй и властвуй!

Уточни что ты имеешь в виду?

Ну у меня есть пешка, например. Или другой актор с компонентами. И есть вот эти модели данных. Я так понимаю, они напрямую никак не привязываются, или всё-таки эти инстансы внутри актора самого лежат?

Ага. А идентифицировать просто по указателю на UObject можно принадлежность к актору?

Можно, но нужно ли и есть ли пути лучше - вопрос открытый. Я бы исходил от архитектуры конкретного проекта все же, чем на generic случай, т.к. надо смотреть откуда данные берутся изначально, рантайм ли это только стейт или какой-то меж-сессионный и так далее.

Согласен.