CzarKirk's analogy helped :).
Sorry for the bump, just wanted to say thx everyone!
Pointer Management
You don't need a "SubsystemManager". In general, any class with the name "Manager" is suspect in its responsibilities.
I believe you should create two classes SDLWindowSystem and SDLTimerSystem, and have them both use a common "SDL" system which tracks SDL initialisation.
I believe you should create two classes SDLWindowSystem and SDLTimerSystem, and have them both use a common "SDL" system which tracks SDL initialisation.
class SDL : noncopyable // e.g. boost::noncopyable{public: SDL() { if(SDL_Init(...) < 0) { throw std::runtime_exception(SDL_GetError()); } } ~SDL() { SDL_Quit(); }};class SDLWindowSystem : public IWindowSystem, private noncopyable{public: SDLWindowSystem(shared_ptr<SDL> sdl); // e.g. boost::shared_ptrprivate: shared_ptr<SDL> sdl;};class SDLTimerSystem : public ITimerSystem, private noncopyable{public: SDLTimerSystem(shared_ptr<SDL> sdl); // e.g. boost::shared_ptrprivate: shared_ptr<SDL> sdl;};int main(){ shared_ptr<IWindowSystem> window; shared_ptr<ITimerSystem> timer; if (m_config.compare("SDL") == 0) { shared_ptr<SDL> sdl = make_shared<SDL>(); window.reset(new SDLWindowSystem(sdl)); timer.reset(new SDLTimerSystem(sdl)); } // Everything cleaned up via RAII // No need for nebulous "manager" classes.}Quote:Original post by rip-off
You don't need a "SubsystemManager". In general, any class with the name "Manager" is suspect in its responsibilities.
I'm not a native English speaker, so maybe I can't find proper word to substitute "Manager", so I used a lot of "Manager".
Any trick to choose the correct name? I always feel headache on that. And I had read some else where in some forum that said "Manager" is not a good word.
Any suggestion?
Manager is a perfectly fine work, normally. The problem is not with the word itself, but the kind of vague classes it represents. What is a "SubsystemManager"? What are its responsibilities?
Manager classes often end up doing too much, and the resulting code can be ugly and riddled with poor dependency separation.
In my proposed design, the SDL class (though admittedly artificial), is responsible for initialising and cleaning up SDL. The SDLWindow is responsible for being a Window, and the SDLTimer is responsible for timing. Finally, because the two types are separate and automatically managed, there is no trouble at cleanup time. Everything unwinds naturally.
Manager classes often end up doing too much, and the resulting code can be ugly and riddled with poor dependency separation.
In my proposed design, the SDL class (though admittedly artificial), is responsible for initialising and cleaning up SDL. The SDLWindow is responsible for being a Window, and the SDLTimer is responsible for timing. Finally, because the two types are separate and automatically managed, there is no trouble at cleanup time. Everything unwinds naturally.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
