Честно говоря, на мой взгляд, решать проблему раздутого класса наследованием вообще не верно, ибо оно не для того придумано. Наследование предназначено для полиморфизма и модульности архитектуры, а также для избавления от копипасты кода. Наследование имеет смысл, когда детей больше, чем один. Даже в Чистом коде об этом есть - каждый следующий узел потомков в наследовании должен представлять из себя дерево, то есть разветвляться. Иначе наследование просто не имеет смысла и создавать кучу родителей и потомков на пустом месте - избыточно. Поэтому решать проблему раздутого класса надо, конечно же, через композицию.

Ну и вот на досуге как-нибудь подумай: может не обязательно хранить ссылку на него как свойство Героя и тем более обеспечивать доступ к его свойствам и методам через геттеры Героя (о чем говорит RedHead90). Может, этот менеджер скиллов может существовать "сам по себе" там, где он собственно и нужен? Ну, конечно, если у всех других персонажей нет никаких скиллов.

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

В любом случае, я очень всем признателен за комментарии. Тема началась ни шатко ни валко, но по итогу раскрутилась-таки. Много чего почерпнул.

Добавлено через 1 минуту
ZergMaster, чистый код - имеется в виду книга Боба Мартина?

Appleman да. Но это не точно

Проблему раздутого класса это точно решит. Но если слепо следовать такому подходу, может появиться проблема большого количества очень маленьких классов.

Тут я не совсем понял. Если ты про тот код, что я привел, то там все компоненты - это публичные свойства. Я просто опустил модификаторы доступа. Это классы-узлы, в которых вообще нет никакой логики, а только публичные поля, указывающие на компоненты. Это тупо списки полей, которые потом автоматом инициализируются с помощью интроспекции или еще как-то.

Послушайте, други,печальную и поучительную историю об импульсивном программировании. Я наконец добрался до Entity-Component-System, пяток статей прочитал (RedHead90, спасибо за наводку), и так меня этот подход вставил, ну просто не по-детски! По крутизне почти MVC, имхо. И загорелся я если не целиком под него переписать, то хотя бы свою частную проблему с раздутым классом персонажа решить. И рефакторил я хрен знает сколько часов на кураже. Выделил отдельные компоненты, схожие по области и логике, кое-где от них ещё унаследовался для реализации специфики, задвинул в них методы обработки данных. На первый взгляд получилось шикарно. Вполне компактный класс Character, к которому подключаются блоки Personality, Parameters, Skills, Statuses и т.п. И все они ни хрена не инкапсулированы. Надо кому со стороны, например, условие проверить - не вопрос! Обращаемся: character.personality[PropID] и вперёд с песней!

Но вот один момент я, блин, не учёл. А он по ходу самый важный. Почему-то мне было невдомёк, что в "чистом" виде все свойства, забитые в Personality и Sexuality, никому не нужны. Причём совсем. Получая, например, значение интеллекта, нужно ещё посмотреть, не надет ли шутовской колпак (WearManager), и не контужен ли наш герой (StatusManager). Короче, тянуть что-то в обход самого "узлового" Character ни фига не получается. А если через него, то теперь у нас не "одно окно" в форме character[PropID], а ещё бухгалтерия с определением, к какому компоненту обращаться.

В общем, сижу-горюю. И обратно к бардаку откатывать неохота, и как это хозяйство без крови организовать не придумывается.