Jump to content
  • Advertisement

PastryCat

Member
  • Content Count

    7
  • Joined

  • Last visited

Community Reputation

100 Neutral

About PastryCat

  • Rank
    Newbie
  1. If you're asking: Do factories provide a clean way of allowing "client code" to have knowledge of only interfaces, then the answer is Yes. [/quote] Yeah that was the direction I was going for ^^ By doing that you're ensuring that you only ever work with abstractions of the concrete objects that gets created by the factories, without having to know certain details of how it needs to be initialized and so forth.
  2. Well actually I did edit my post the second you replied to add the fact that you could use it to force interfaces onto the client code, so polymorphism would be used as a clean way of working with the returned objects, if that was your point?
  3. I think maybe in those kind of situations, the problem is I don't really have enough experience to be able to see when you would actually need code that's pretty much completely careless of anything that gets made or returned? In what relations you would actually have a use for that? (other than maybe again as I said, forcing an interface to the client code so it uses polymorphism for whatever it needs to hide the concrete type of?)
  4. So in that case you would pretty much use factories when the client doesn't actually need to know anything about the specific implementation of a sub-system, it just needs to be able to call the same general methods without caring about how that's actually done for each sub-system? Also, would it then be appropriate to have several types of factories returning different types of base classes, obviously following that the way they need to be created is a relevant problem for the factory pattern? For example in one project, have a factory which returns UIElements, a factory which returns game objects, and so on? Seeing as they might have very different implementations and the client code handling each type would probably need to know specific general things, but for each category. And yeah, the usage of patterns by simply using it with your design when a relevant problem occurs seems so obvious, but I've been clouded a bit these last couple of days
  5. Now I just got a much clearer idea of when a factory pattern should be applied, thank you all very much And rip-off, I especially took good notice of the last line in your post ^^ Puts things into a much better perspective, as I think we've actually tried to implement our design around the potential use of the factory pattern, and as it is right now it actually does look quite pointless for our current design. Time to refine it, hopefully the end product will be much better I'm pretty certain this has been a case of "design fever"
  6. [color="#1c2837"]Aaaah interesting, so essentially a factory only really becomes useful when there is additionally logic related to the initialization of an object? That is, you actually need to do more than simply doing an initialization with "new myType"... etc? [color="#1c2837"] Sounds reasonable about the abstraction level aswell, I'll see what way might be better to categorize the objects [color="#1c2837"] Thanks a bunch for the reply!
  7. [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!
  • 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!