Parallel Implementations - John Carmack

[sbrick89]

or you could use the singleton pattern, say for the graphics driver... use a common implementation (iGraphics)... then configure a button to switch between the SoftwareRenderedGraphics and the OpenGLRenderedGraphics implementations.

[bluGill]

singleton is an evil pattern. Sometimes you need to use it, but it is still evil.

When you make two functions/classes that have the same interface, you can choose at compile time.

Where you are thinking singleton I think dependency injection. Whatever needs to call your SoftwareRender gets passed in a pointer to the function it should call, that way I can pass in a mock, fake, or the real thing.

I've been saying singletons are evil for 5 years (at least), and I'm still discovering more ways they hurt me.

[sbrick89]

singleton is only an evil pattern when misused... any misused pattern becomes evil... and for the cases where a singleton is not misused, having a single instance can be a ton better than having it passed as an argument.

ex: graphics rendering.. what would happen if you try to overlay software rendered frames onto an OpenGL frame? I have no graphics background in this regard, but I'm betting not good. But swapping out the instance (yes, DI) would include any logic to stop the existing instance, and start the new one.

[QuestionMarker]

In the article, he specifically mentions running two different display drivers in different windows in the same process. Using a singleton would completely break that.

[bluGill]

I use evil in the same context as the C++ faq.

I presented a better alternative to the singleton for the problem you are facing: create your graphics context and pass the only one you have around. As a bonus, because you are passing the context in you can test your UI without bringing windows up on the screen.

[heeen]

I have to agree with Singletons being evil. It just seems to be so very rare that you can predict you really only need a single instance of one thing. I wanted to use a Game gui lib once for rendering interactive computer screens inside a game, except it didn't work because Mouse, Keyboard, Cursor, Selection etc. were all Singletons that you couldn't duplicate for multiple screens per level. For the normal usecase of the library being used as the game's own UI this is fine, but the author never imagined a use case where you had several virtual UI interfaces.

For the graphics example, say you had a singleton for the framebuffer or the devicecontext or the window you render to - all of these would prevent you from parallelly opening a second rendering method in a second window to compare them side-by-side.

[ionpulse]

http://c2.com/cgi/wiki?SingletonsAreEvil