C++: Unsure about class - class manager relationship

In my project I have a series of classes where their instances are manged by some manager class, for specific reasons.

Examples would be:

CSound - Abstracts a single sound

CSoundManager - Friend of CSound, provides factory methods for creating CSound instances, mixes active sounds together

Also: CFont, CFontManager (for font access per-name), CSprite, CSpriteManager (for drawing each frame), and so on.

Here my first questions already:

• Is what I'm doing a specific named design-pattern?
• Is it in most c开发者_运维百科ases, for whatever reason, a bad idea? If yes, why?

Then, I have asked myself:

• How should the objects be created and destroyed? Should I permit creating them on the stack or directly with new, or only by the methods of the corresponding manager class?

(also for destruction: delete myFont; versus. FontManager.DestroyFont( myFont );)

Sounds like you may be violating the The Single Responsibility Principle (SRP) principle.

Is the CSoundManager class responsible for creating and managing the lifetime of CSound objects, or is it in charge of mixing active sounds together? Names can tell you much, and "Manager" can be understood in too many ways...

Generally, if you want these Manager classes to handle the lifetimes of your objects, then they should most likely be the only way to instantiate these objects (i.e. private ctors in the objects). See the Factory Design Pattern, although your implementation is a bit different.

If you do this, then the client code should never call new or delete. Manually calling delete is bug-prone, and should be avoided using idioms such as RAII. In this particular case, the Manager class should manage the lifetime of objects, and therefore delete will never appear in client code.

Looks like you are using some form of Factory design pattern. Not sure what makes you feel its a bad idea.

If you are treating Manager as container of the objects then it would control the life cycle of these objects. However if your objects need to live beyond the life of Manager then you would create them with new and Manager may not be responsible for destruction.

Generally what you're implementing is a Factory Method Pattern wherein an object allocates another object. However, you are not reaping the benefits of a Factory class as you're directly tying the allocated type to the factory as opposed to allowing the factory to manage all the internals abstractly. For instance, can you do this from any file, or just the factory for that resource type (CSoundManager): new CSound();

If so, you're missing the point and you basically just have a Singleton that allocates and manages an object. Consider abstracting your resource types. If CSound and CFont derived from IResource, you could have a CResourceManager that would just take an enum or some sort of identifier for that type and reduce coupling and dependencies in your codebase. Whenever you needed to use that object you could expose the type but more likely than not you could use an abstract manager (CResourceManager) to handle those objects using common interfaces (Update(), Create(), Destroy() etc...).

For your sound manager case, remember that sounds need only be loaded once and can be instanced with a unique state. In that right, have the resource manager manage the actual resource (CSound), and the sound manager (CSoundManager) maintain discrete instances (e.g. CSoundInstance) and manage mixing (via CSoundMixer). Specialize your classes in meaningful ways that manage complexity and reduce redundancy.

I used the sound manager as an example but this holds true for most io systems (graphics, input, physics).