Дать им удобные префиксы. С более сложным не сталкивался.

Если это ты его написал — переписывай, разделяй. Если он тебе такой достался — плюйся.

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

перейди в другой класс

Тред не читал

Выгнать парочку в коридор

Что делать если у класса слишком много членов.

Порнуха какая то :)

Что делать

прямую реализацию

с такими тегами ты через 3-4 месяца сделаешь cetjs2 печальным, а вместе с ним - половину ЛОРа. Нехороший ты человек.

Важно не то, сколько у класса членов, а сколько у него ответственностей. В идеале, класс должен иметь только одну ответственность, только один возможный повод для изменения. Это буква S в принципах SOLID.

Если в вашем примере класс только делегирует вызовы, то, возможно, с ним все в порядке. Можно попробовать разделить «вызовы извне» на несколько типов и соответственно заменить один большой адаптер на несколько поменьше. Ну и завести класс-диспетчер, чтобы он переадресовывал вызов нужному адаптеру.

Посути класс является прокси для вызовов из вне. Для удобства.

А в чём удобство-то?

для начала - посмотреть, не объединяет ли класс необъединяемое, разделить при необходимости. Потом чистить и объединять методы фасада (обычно это удается)

Можно не держать в голове все остальные имена классов, а делать все через один-единственный. Удобно.

Что делать если у класса слишком много членов.

у нас наоборот в школе девочек больше было

Рефакторить. Если этот класс один такой, то может получиться несложно, если они все такие — то, увы.

Лучше разнести члены по отдельным классам (см. слабая связность и single responsibility), и, если не хочется светить в паблике внутренностями, сделать для каждого по интерфейсу или pimpl-у. Мешать всё в кучу - плохо, при правке запутаешься, никакого удобства здесь нет.

расчленить

Скоро церковь и линукс запретит, с членами, демонами

Эргономика текста - дело тонкое. Нет универсальных верных ответов на такие вопросы.

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

class Dog;

class Ears
{
private:
  Dog* owner;
public:
  inline Ears(Dog* _owner)
  :owner(_owner)
  {
  }
};

class Feet
{
private:
  Dog* owner;
public:
  inline Feet(Dog* _owner)
  :owner(_owner)
  {
  }
};

class Tail
{
private:
  Dog* owner;
public:
  inline Tail(Dog* _owner)
  :owner(_owner)
  {
  }
};

class Dog
{
public:
  Ears ears;
  Feet feet;
  Tail tail;

  inline Dog()
  :ears(this),feet(this),tail(this)
  {
  }
};

Здесь класс «собака» содержит малые классы «уши», «лапы» и «хвост».

А ООП-программисты чем-нибудь кроме моделирования животных и машин занимаются?