- Forum
- General C++ Programming
- Dependency injection and very mighty cla
Dependency injection and very mighty classes? Right choice?
Hi folks!
Since I'm currently implementing a Core OpenGL based rendering engine as a library, I find myself confronted with a very common design issue and the, quite frankly, mind torturing question whether to use or to abandon all singletons and globals etc. On the one hand there are implementations of this type which almost abuse the pattern, like Ogre3D, and still they are easy to use and do the job quite well. On the other hand using singletons really does leave you with some problems which have to be bypassed in order to make them work correctly.
I made the decision not to use them as to not leave any room for another dispute about singletons, but I'm not completely sure of my take either. So here's what I've been thinking about how to implement my library:
1. The
2. Although it seems as if limiting the number of instances of Renderer to exactly one copy is correct for my special usage scenario, not doing so will not create any problems if the following holds:
a) a Renderer can be created multiple times as it simply creates another GL context and the last instance created will reference the current context. This may be a legitimate use-case as rendering to different contexts is not unusual and switching requires the invocation of MakeCurrent() for a specific context anyway.
b) Governed by 1., a user will most likely not want to create instances of components of the renderer and most likely use only one instance of the class itself. If they feel only one renderer instance is desired in their application, they can still feel free to use it as a global or use it via a singleton template themselves or employ dependency injection.
3. Users will most likely not want to know about the internals of the library but simply use it. All they need to know is that the implementation guarantees the existence of only instance of every object which is expected to be created once for each instance of renderer.
What do you think about my reasoning? Should I take a look at the Facade and Proxy patterns, which seem like they might really work for me? Do you know alternatives to creating a monolithic
Thank you so much for your help and insight.
Thomas
Since I'm currently implementing a Core OpenGL based rendering engine as a library, I find myself confronted with a very common design issue and the, quite frankly, mind torturing question whether to use or to abandon all singletons and globals etc. On the one hand there are implementations of this type which almost abuse the pattern, like Ogre3D, and still they are easy to use and do the job quite well. On the other hand using singletons really does leave you with some problems which have to be bypassed in order to make them work correctly.
I made the decision not to use them as to not leave any room for another dispute about singletons, but I'm not completely sure of my take either. So here's what I've been thinking about how to implement my library:
1. The
class Renderer is composed of several necessary objects which are created by a default implementation and are used by invoking the respective public interface exposed by class Renderer. This might include logging facilities, scene and resource management etc. This way, the only object that would ever need to be explicitly created for using the default implementation is an instance of said class. If the default implementation does not provide the envisaged behavior, a custom overload of a component may be used. Serious problem: class Renderer will be extremely monolithic.2. Although it seems as if limiting the number of instances of Renderer to exactly one copy is correct for my special usage scenario, not doing so will not create any problems if the following holds:
a) a Renderer can be created multiple times as it simply creates another GL context and the last instance created will reference the current context. This may be a legitimate use-case as rendering to different contexts is not unusual and switching requires the invocation of MakeCurrent() for a specific context anyway.
b) Governed by 1., a user will most likely not want to create instances of components of the renderer and most likely use only one instance of the class itself. If they feel only one renderer instance is desired in their application, they can still feel free to use it as a global or use it via a singleton template themselves or employ dependency injection.
3. Users will most likely not want to know about the internals of the library but simply use it. All they need to know is that the implementation guarantees the existence of only instance of every object which is expected to be created once for each instance of renderer.
What do you think about my reasoning? Should I take a look at the Facade and Proxy patterns, which seem like they might really work for me? Do you know alternatives to creating a monolithic
class Renderer?Thank you so much for your help and insight.
Thomas
Last edited on
Topic archived. No new replies allowed.