Was just doing some work on the new "engine," and had the software-engineering bible, Design Patterns, out. To make a short story even shorter, I realized that my engine needed to support a few core C++ "extensions" (not talking STL shit here, kids), such as templates for factories and singletons. The whole singleton thing is pretty self-explanatory; if you dont' know what one is, you need to be shot... Either that, or you just need to learn more.

Anyway, what I was just realizing that people commonly confuse the purpose of the "Abstract Factory" pattern, and the "Prototype" pattern. The two patterns are competing against each other for the same goal, but they can also be used together; the latter of which is what people generally use, and call it either a "Prototype" or a "Factory." Oddly enough, they perform very different functions, but are very similar in nature. Both of these patterns share the same goal: they enable the program to determine what interface(s) it is going to use in the application at run-time, thus increasing the "elegance" of the program's code, and making it a whole hell of a lot easier to update. The pattern you choose, however, is primarily up to you. Or, as was stated, you can use both. Just be sure you know the differences between the two patterns, as is discussed below:

• Abstract Factory Pattern - This pattern is, primarily (as the name may tell you), used to keep consistancy between the various sub-classes that you may have floating around your program. This pattern is not, however, meant to be a Singleton. It can be used in conjunction with the Singleton pattern, but it's not meant to be a Singleton in and of its own. This pattern should, primarily, be used as a means of keeping consistancy between, and managing a series of, concrete sub-classes (which ARE typically Singletons).
• Prototype Pattern - This pattern is primarily used as a template for concrete sub-classes. It is, almost, like a design document for the functionality that you want its sub-classes to inherit. As a real-life example, I'm currently creating a prototype rendering interface. This prototype contains purely virtual functions that create/destroy (my name for initialization and shutdown functions) the sub-class, and also perform all sorts of operations that use the rendering device. I will, then, derive specific rendering classes from this prototype that handle Direct3D9 rendering, OpenGL rendering, and maybe even a renderer capapble of software rendering. Now, granted the prototype's functions are purely virtual, which means they don't do shit on their own; however, their sub-classes must inherit, and define, all the behavior that the prototype declared. This, essentially, makes the prototype class a blueprint; one that the sub-classes must follow.

There ya go, a little technical entry in my blog. Enjoy... Or I'll hunt you down with mittens, and we'll turn you loose in my giant human gerbil habitat house.