Если дать короткий ответ, то всегда следует задуматься о декомпозиции класса в такой ситуации.
Подобный твоему класс представляет из себя монолит - довольно распространенный примитив проектирования, попутно именуемый как "God Object". Объект, который может всё и от которого все вокруг зависят.
Если появляется желание разбить реализацию интерфейса класса на несколько файлов, значит уже есть понимание того, как тематически декомпозировать этот класс и, вероятно, проблема остается только в том, чтобы правильно декомпозировать состояние класса.
Декомпозировать в этом случае надо. Таким образом повысится структурность кода, пригодность к дальнейшему исправлению, понятность для читателя кода. И отношения между элементами композиции станут более явными внутри целевого класса.
Если говорить развернуто.
В ряде случаев дальнейшую декомпозицию провести возможным не представляется в виду того, что функциональная нагрузка на класс является динамично растущей или просто большой.
В таких случаях люди и приходят к тому, чтобы провести тематическое разделение интерфейса класса и его реализаций. Интерфейс класса делится на тематические секции внутри своих областей доступа. В это же время, каждой тематической секции интерфейса соответствует свой файл исходного кода класса.
Такой подход позволяет лучше понять структуру большого класса, найти места его дальнейшей декомпозиции. Класс с тематическим разделением легче читать, в нем легче ориентироваться при анализе поведения. Так же такой класс легче дополнять, т.к. писатель освобождается от мук выбора места, куда нужно добавить новый метод или поле, ему все должно быть понятно по тематике добавляемого кода.
Общий шаблон такого разделения выглядит так. Чаще всего разработчики именуют файлы именем класса. Например MyClass.h и MyClass.cpp. Когда нужно тематически разделить определение интерфейса, к имени класса после точки и перед расширением файла добавляется суффикс, говорящий о тематике определения. Например MyClass.serialization.cpp, MyClass.crud.cpp или MyClass.callbacks.cpp.
