C ++: не уверен насчет класса - менеджер класса - PullRequest
2 голосов
/ 08 марта 2011

В моем проекте у меня есть серия классов, в которых их экземпляры управляются неким классом менеджера по определенным причинам.

Примеры будут:

CSound - Абстрагирует один звук

CSoundManager - Друг CSound, предоставляет фабричные методы для создания Инстансы CSound, микширует активные звуки вместе

Также: CFont, CFontManager (для доступа к шрифту по имени), CSprite, CSpriteManager (для рисования каждого кадра) и т. Д.

Вот мои первые вопросы уже:

  • Является ли то, что я делаю, конкретным именем-шаблоном дизайна?
  • Это в большинстве случаев, по какой-то причине, плохая идея? Если да, то почему?

Тогда я спросил себя:

  • Как объекты должны быть созданы и уничтожены? Должен ли я разрешить создание их в стеке или напрямую с new, или только методами соответствующего класса менеджера?

(также для уничтожения: delete myFont; против. FontManager.DestroyFont( myFont );)

Ответы [ 3 ]

1 голос
/ 08 марта 2011

Похоже, вы нарушаете принцип Принцип единой ответственности (SRP) .

Является ли класс CSoundManager ответственным за создание и управление временем жизни CSound объектов, или он отвечает за смешивание активных звуков вместе?Имена могут многое сказать вам, и «Менеджер» может быть понят слишком многими способами ...

Как правило, если вы хотите, чтобы эти классы Менеджера обрабатывали время жизни ваших объектов, то они, скорее всего, должны быть единственнымиспособ создания экземпляров этих объектов (то есть частные ctors в объектах).См. Factory Design Pattern , хотя ваша реализация немного отличается.

Если вы сделаете это, то код клиента должен никогда вызывать new или delete.Вызов delete вручную подвержен ошибкам, и его следует избегать, используя такие идиомы, как RAII .В этом конкретном случае класс Manager должен управлять временем жизни объектов, и поэтому delete никогда не появится в клиентском коде.

0 голосов
/ 16 марта 2011

Как правило, вы реализуете шаблон фабричного метода, в котором объект выделяет другой объект.Однако вы не пожинаете преимуществ класса Factory, поскольку напрямую привязываете выделенный тип к фабрике, а не позволяете фабрике абстрактно управлять всеми внутренними объектами.Например, вы можете сделать это из любого файла или только с фабрики для этого типа ресурса (CSoundManager): new CSound ();

Если это так, вы упускаете точку и в основном у вас есть только Singletonкоторый выделяет и управляет объектом.Рассмотрите возможность абстрагирования ваших типов ресурсов.Если CSound и CFont являются производными от IResource, у вас может быть CResourceManager, который просто получит перечисление или какой-либо идентификатор для этого типа и уменьшит связи и зависимости в вашей кодовой базе.Всякий раз, когда вам нужно было использовать этот объект, вы можете предоставлять тип, но, скорее всего, вы можете использовать абстрактный менеджер (CResourceManager) для обработки этих объектов с использованием общих интерфейсов (Update (), Create (), Destroy () и т. Д.).

В случае вашего менеджера звука помните, что звуки нужно загружать только один раз, и их можно создавать с уникальным состоянием.В этом праве менеджер ресурсов должен управлять фактическим ресурсом (CSound), а менеджер звука (CSoundManager) поддерживает отдельные экземпляры (например, CSoundInstance) и управляет микшированием (через CSoundMixer).Специализируйте свои классы осмысленными способами, которые управляют сложностью и уменьшают избыточность.

Я использовал диспетчер звука в качестве примера, но это справедливо для большинства систем ввода-вывода (графика, ввод, физика).

0 голосов
/ 08 марта 2011

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

Если вы рассматриваете Manager как контейнер объектов, он будет контролировать жизненный цикл этих объектов. Однако если ваши объекты должны жить дольше, чем у менеджера, вы должны создать их с новым, и менеджер может не отвечать за уничтожение.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...