OOP Design Patterns

They are probably along the lines of these:

Double Dispatch, Visitor (collision detection),
Factory, Prototype (savegames, spawning),
Facade, Adapter (wrappers),
Chain of Responsibility (file recognition),
Flyweight (particles)

You'll surely find more, if not the full range of the GoF book, in a professional game engine written using OOP.

-Markus-

Sure, you could do that also. I was just giving examples where I saw those patterns would be useful.

The chor pattern would be useful if you decided to go and let each FileDecoder or whatever objects you've got open the file and check whether the file's header is a format it knows.

-Markus-

Quick question, is Singletion good for the graphics wrapper?

Singleton is the most over- and missused pattern of all. You can use it for almost anything and it "makes things so easy" to code, but it makes it a hell to maintain and expand - or for outsiders to understand the flow of the program.

Just don't do it...

Agreed. In C++, the only good typical reason for bothering with one is to solve problems with static order of initialization. In some other OO languages (including Java), such problems do not exist (unless you have a circular dependency, in which case you're screwed regardless).

Consider static interfaces or various forms of Monostate, and proper use of namespaces to restrict scope.