Jump to content
  • Advertisement
Sign in to follow this  
masterball

Design Patterns: Factory vs. Factory Method ?

This topic is 513 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I can't find any real difference between a "Factory" design pattern vs. a "Factory Method" design pattern.

 

Are they essentially the same thing, but a "Factory Method" implementation provides an interface to an existing implementation of a "Factory" design pattern?

 

Note this question has nothing to do with an "Abstract Factory" design pattern.

Share this post


Link to post
Share on other sites
Advertisement
I don't have my copy of the Gang of Four handy at the moment, but as I recall... Factory Method is a virtual method that allows derived classes to construct objects of different types, and the Factory is just the whole shebang.

Wikipedia may have some additional clarification.

Share this post


Link to post
Share on other sites

As I remember and understand it:

 

Factory - some object or function that creates and returns other objects. This isn't a 'pattern' in the GoF Design Patterns sense, but you can think of it as a very simple one if you like.

 

Factory Method - a pattern where derived factory classes may override a base factory method to return different objects depending on the type of the factory. e.g. You might have a CharacterFactory, from which you derive MonsterFactory and PlayerFactory, all implementing CreateCharacter.

 

Abstract Factory - is arguably just a twist on Factory Method where the factory is an abstract interface, usually encapsulating several related construction methods.

Share this post


Link to post
Share on other sites

Factory - some object or function that creates and returns other objects. This isn't a 'pattern' in the GoF Design Patterns sense, but you can think of it as a very simple one if you like.


I am curious: Why wouldn't this qualify as a pattern?

Share this post


Link to post
Share on other sites

Well, it's not a GoF Design Pattern as it's not in the book. I don't think that 'a function that makes things' would have been a complex enough concept to warrant its entry, unless the book was about assembly language or similar. I don't have a strong feeling over whether people want to call it that or not, however.

Share this post


Link to post
Share on other sites

I am curious: Why wouldn't this qualify as a pattern?

 

The original book was mostly their formalization of patterns they had observed and discussed in their consulting and teaching careers.  

 

They were saying "We've seen these hundreds of times with various names, let's give them more formal names and study them."  Their original book wasn't a catalog of all patterns, nor meant to exclude anything. They were quite clear about this in the introductions. 

 

They succeeded in adding a new aspect to computer theory.  Before their work it was primarily about algorithms and data structures.  After their work there were still algorithms and data structures, and also design patterns of applying the algorithms. Design patterns are now studied as higher-order algorithms in most computer science studies.  Many patterns that didn't have names before now have names. Unfortunately the common ones now tend to have multiple names, but they're still easily recognized and better understood than they were before.

 

 

Regarding factories themselves:

 

There are many variations on 'factories' and 'builders', they all create things.  Some create specific objects, that's a typical factory. Some create abstract objects or an object that implements an interface, that's an abstract factory. Some set contents to known values, that's an initializer or a builder. Some set content based on direct parameters, which may be a factory or a builder. Some factories and builders set content to values read from a stream. Some set content based on other reasons, which is commonly seen in procedurally-generated worlds.

 

You might have a series of factories for loading a game from a save file. You pass it a pointer to a scene graph and a stream to read from. The factor parses a little of the stream and says "this is a monster". It passes it to the monster factory, which says "this is a blue slime with health 23 of 40, empty inventory, location (x,y)".  That monster is generated and returned back to the parent factor. The original factory reads the next item in the save file, and the various factory components build all the items that were in the save file.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!