Выбор дизайна для звуковых эффектов

Question

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

1) Создайте абстрактный интерфейс SoundEffect и получите от него все звуковые эффекты. У каждого звукового эффекта свой класс. После создания он открывает звуковой файл и воспроизводит, а после уничтожения закрывает файл. Основным недостатком этого подхода является то, что у меня будет много очень маленьких объектов, которые значительно увеличат количество файлов. Я мог бы поместить несколько звуковых эффектов в один заголовок (связанные), но я не уверен.

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

Очевидно, что я спорю о подходе ООП против более "традиционного" подхода, и мне интересно, какой здесь лучший выбор дизайна. Я сильно склоняюсь к подходу ООП, но я не уверен, как я хочу структурировать файлы. Если у вас есть другие рекомендации, я буду рад их услышать.

Answer 1

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

Так что для звуков не имеет особого смысла знать, как играть самим. В итоге они будут бороться за контроль над единственным ресурсом - звуковым устройством.

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

Лично, если бы не пропускали звуковые эффекты с классом, данные - это данные, на самом деле нет необходимости заставлять КАЖДУЮ часть данных иметь методы. Вы можете злоупотреблять классами, которые вы знаете.

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

Answer 2

Если я правильно понимаю, вы жестко программируете звуковые эффекты для всех возможных звуков?

Звучит неправильно, вы создаете разные подклассы для различного поведения, а не для разных данных.
Если у вас есть определенные типы звуковых эффектов, которые требуют предварительной обработки данных, подклассы имеют смысл - если проект больше, вы можете захотеть разделить код обработки эффектов и параметры эффектов, чтобы вы могли изменять эффекты без перестройки приложения (например, FMOD Разделяет кодирование и звуковое оформление).

Для воспроизведения разных звуковых файлов просто позвольте конструктору класса взять путь или некоторый идентификатор ресурса для звукового файла - здесь не требуется switch.

Если вы имеете дело с большим количеством звуковых файлов, которые используются неоднократно, был бы полезен подход на основе пула, чтобы избежать перезагрузки файлов при каждом их воспроизведении. Одним из подходов к этому является шаблон flyweight (см., Например, Boost.Flyweight для реализации).