A personal example. Just when I started college, was trying to write a 3D game in C++ (I was young, so yeah, I thought it was just C with classes, LOL). Since

A personal example. Just when I started college, was trying to write a 3D game in C++ (I was young, so yeah, I thought it was just C with classes, LOL). Since I had no idea about design patterns, so I made a singleton called "Rendering Manager" that took care of "everything-OpenGL". I would have numerous classes, like CHuman, CHero, CParticle, CBuilding (it was more abstract but whatver) and stuff like that that inherited from something like a CDrawable, which had a CDrawable::Render() method. The problem was that the CDrawable::Render() would call the singleton by itself, so it had a direct dependency with the Rendering Manager. If I had to change something on the singleton, I'd have to change a lot of other classes. When I needed to render on different "virtual screens", for reflections, shadows, cameras (yes, it was funky lol), I had to put global state on the singleton in order to make it render things in different ways. When I needed LOD (level of detail), I had to pass the camera position via a global, only adding more globals to the mess. Of course, I was just a student back then, but failing spectacularly taught me a lot of new things. -- What I would have done today: CDrawable objects would only worry about their own geometry and transformations and would be ignorant about the glorified-OpenGL-wrapper. Instead, we could have a "Scene Manager" (which doesn't even have to be a singleton anymore) that "visits" each object to "ask" them just enough to get them rendered.