[font="arial, verdana, tahoma, sans-serif"]Hello everyone
I'm currently on my way to finish first year of my computer science education, and just a while ago we were introduced to design patterns, namely the more simple ones as the famous singleton pattern, as well as the different sorts of the factory pattern as starters.[/font]
Now it seems that most of my professors have quite a different idea of their definition and practical use of the factory pattern. I've been researching a bit around the internet and I am now officially lost in what actual practical use it has, what's the real meat of the pattern?
The two current core ideas I've been explained are as follows:
1) Provide a general interface for all objects (especially counts toward the method factory as I understand it? Since you're able to hide the actual implementation and just return an interface type the client code can use).
2) Remove initialization logic from the client code (things like parameters and the like), to collect all this logic in one unit so it's easier to quickly make changes should your classes suddenly require additional parameters (instead of having to jump around in 10 different classes in the client code initializing the same object to add the newly introduced parameters.
Now for a current project we're doing, me and my group have tried implementing the factory pattern as a part of our core design. But we've quickly run into a couple of design related questions, and they're kinda big! First of all, how are you supposed to handle parameters if you need to provide this when using the factory? For example, we have a UIElement factory from where we want to initialize things like menu buttons and so on, but the menu button class constructor requires a screen position, as well as what game state to change to upon click and so on. It seems impossible to be able to do this through a factory without providing a parameter array to the factory create method, but this approach would seem to contradict the second reason I mentioned above, thus defeating the purpose of the pattern in the first place. On various other sites on the other hand, they say using parameters with a factory is perfectly okay, although I also personally think providing this parameter array isn't really good design as the client code will have to know exactly what objects require what set of parameters, which actually also contradicts the first idea I mentioned. What is the best approach to doing this?
Also, how literal are you supposed to take the general interface part? In our current design we have factories to create UIElements, game objects, screen objects and so forth, and they all return an interface type of the name IUpdateable (which is just an update and draw method), is it generally a good idea to try and use that much abstraction? Also as a note, the client code do not have access to these sub-factories, but they all call a FactoryManager which will check each factory for the object type the client code called the method with, see which one can create it, and then call the CreateObject method from that factory.
Well, I think that was about it My head is actually very confused right now regarding these things, and I've seen to become stuck, not knowing in which direction to move. I hope there's some experienced software engineers out there willing to lend a hand
Thank you all for your time, any help is really appriciated!