Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views


Sign in to follow this  


So I hear about this design pattern "factory." Basically if you want a core component of a system, you call


or maybe


Ok, I can see some benefits of that. But really, what's the point? I've decided that I like having a few globals. Simply pointers to the core components of the system.

If you have all the factory methods in one place, one base class for example, that class depends on all of those component's, and if you ever want to include that class you'll have to include all of those component's header files as well.

If you split those methods up, that works. But seriously, what's the point? It just adds confusion in my opinion. In my system right now I have main header files for each part of the system, like AXGraphics, AXCore, AXSound, etc. In each one of these main headers, an extern global pointer is declared, such as:

extern AXRenderer *AXAppRenderer;

in AXCore, when the system is initializing, it declares all of these pointers and initializes them to an appropriately initialized object.

So, when you include AXGraphics.h, you can use AXAppRenderer and the appropriate renderer will be used. Why not do it this way? For my system, there should only be one renderer, one window, etc, so those are singletons, therefore it's not like you can screw up the system by creating a new one and pointing the global pointer to it.

Plus, I hate doing stuff like AXRenderer::Instance().Method(). I just hate it.

Not saying it's the best way, but it's just what I'm thinking right now. Thoughts?
Sign in to follow this  


Recommended Comments

I don't think you've got the pattern right. There are several different factory design patterns. The GOF defined the Abstract Factory and Factory Method patterns. Furthermore there are other creational patterns as well, for example Builder and Prototype.

Share this comment

Link to comment
You're probably right, I've been researching patterns but haven't really read a good example why there actually needs to be this factory class where I call rendererFactory->GetRenderer().

I think I'm doing something similar to the abstract factory pattern. AXRenderer is an abstract class, and I have DirectX and OpenGL renderers that implements the code.

The object creation is done in the system initialization though. It detects the type of objects needed or requested, creates them, and sets the pointers to them.

So you could either use those pointers or call AXRenderer::Instance() to get the object.

Because even if I used a factory class, I still would like to create a pointer that points to the object returned from factory->GetAbstractObject(). that's basically what I'm doing anyway.

EDIT: I'd also like to clarify that I'm mainly talking about using factory methods with core system objects. I can definitely see the use of a factory pattern in general, but when dealing with what type of renderer, what type of window and such, I don't have any problem including this code in the base system init function.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!