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

Question

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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