Question

What are the pros and cons of using a singleton class for sound management?

I am concerned that it’s very anti-OOP in structure and don’t want to potentially get caught up going down the wrong path, but what is a better alternative?

Answer 1

It’s an awkward topic but I’d say that a sound manager style class is a good candidate for a class that should not be initialized.

Similarly, I would find it OK if a keyboard input manager style class was a completely static class.

Some notes for my reasoning:

• You would not expect more than one instance that deals with all sounds.
• It’s easily accessible, which is a good thing in this case because sound seems more like an application-level utility rather than something that should only be accessed by certain objects. Making the Player class for a game static for example would be a very poor design choice, because almost no other classes in a game need reference directly to the Player.
• In the context of a game for example, imagine the amount of classes that would need a reference to an instance of a sound manager; enemies, effects, items, the UI, the environment. What a nightmare – having a static sound manager class eliminates this requirement.
• There aren’t many cases that I can think of where it makes no sense at all to have access to sounds. A sound can be triggered relevantly by almost anything – the move of the mouse, an explosion effect, the loading of a dialogue, etc. Static classes are bad when they have almost no relevance or use to the majority of the other classes in your application – sound does.

Anyways; that’s my point of view to offset the likely opposing answers that will appear here.