Home/ Questions/Q 585419
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T15:00:03+00:00

I’m trying to decide how I want to implement sound effects in my program.

  • 0

I’m trying to decide how I want to implement sound effects in my program. I’ve debating between 2 options.

1) Create an abstract interface SoundEffect and have every sound effect derive from that. Each sound effect is its own class. Upon construction, it opens the sound file and plays, and upon destruction it closes the file. The main drawback I see to this approach is that I’ll have a lot of very small objects which would greatly increase the number of files. I could put multiple sound effects in a single header (ones that are related), but I’m not sure.

2) Since the playing of any sound effect calls the same stuff, with the only difference being the file it opens, I could create a single SoundEffect class, with its constructor being an enumerator that contains the names of the sound effects. The class would use a switch to play the appropriate sound.

Obviously I’m debating over an OOP approach vs a more “traditional” approach, and I’m wondering what the best design choice is here. I am heavily leaning towards the OOP approach, but I’m not sure how I want to structure the files. If you have any other recommendations, I’d be glad to hear them.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    If i understand that right you are hard-coding the sound effects for all possible sounds?

    That sounds wrong, you create different subclasses for differing behaviour, not for differing data.
    If you have certain sound effect types that need preprocessing of the data, subclasses make sense – if the project is bigger, you might want to seperate effect handling code and effect parameters so you can change effects without rebuilding the application (e.g. FMOD seperates coding and sound design).

    For playing different sound-files just let the class’ constructor take the path or some resource id for the sound file – there is no switch needed here.

    If you’re dealing with a large number of sound files that are used repeatedly, a pool based approach would be useful to avoid reloading of files every time you play them. One idiom for that is the flyweight pattern (see e.g. Boost.Flyweight for an implementation).

    • 0