Factory Design Pattern

[Flash Gordon]

Does anybody actually use Factory Design Pattern?

Seems like a load of whoey, or O'Reilly's team isn't very good at explaining anything within a practical application.

[senocular]

I do. My Mii Editor ( http://www.miieditor.com ), for example, uses a factory to create instances to manage the loading and saving of files. A factory is used because depending on whether or not the application is being run as an AIR app or from a web page, different classes are used to handle the load and save operations. Its the factory's responsibility to determine which instance is needed and returns that to the main application.

[Flash Gordon]

Okay. thanks for the response. I wont rule it out then.

Do you have a suggestion for a small application that would/could/should use this pattern that I can try to build so I can post it up for criticism?

[senocular]

As in an excuse to write something that uses it?

[Flash Gordon]

Yea, i can't seem to wrap my head around its usefulness or what would I need to use it for or when.

[senocular]

Basically its when you have a need for one or more objects with you having a collection of many objects that facilitate the need but given your current circumstances should only be using one type of those objects.

For example, you need to display a set of OS components on the screen but, as is the case with Flash, your environment does not support native OS widgets. So what you have done is recreated each supported OSs' widgets for your application from scratch. However you will only want to display your Mac OS widget components when playing on the Mac and Windows OS widget components when on Win. To do that you would have two factories, a WinComponent factory and a MacComponent factory each of which create the same widget components with the same functionality but does so in 2 different visual (and behavioral) styles. Which factory to use will be determined at startup when the OS is detected.

var componentFactory = (OS == "Mac") ? MacComponentFactory : WinComponentFactory;
addChild(componentFactory.newButton());
...

[Flash Gordon]

Ok, I think I understand it a little. So an other example might be:

A users enters their birthday. Based upon their age, their avatar character is either a baby, teen, young adult, or old fogy. All of these characters would extend a basic "Character" abstract class and therefore share some of the same method signatures.

The point of a Factory Pattern is to loosen the coupling between the client and the class, correct? When using a Factory pattern adding additional stuff later on should be easier and require no changes to current code, but adding more code?

[senocular]

I think you're getting it : )

[Flash Gordon]

cool. Let me see if I can find a way to put this to use and post up an example in a day or two.

Thanks senocular for the help. The concepts of OO had be kind of hard to wrap my head around as they are never a direct line of sight...always the long way around.

[hangalot]

senocular's example is what you call an abstract factory. this is where you create a class according to your needs that has the same methods as an interface which all these class you can create implements, and this class gives you the specific feedback you desire.

this is prob the least used type of factory. a different type of factory is the factory method.

lets say for example i havce a piece of xml that defines which controls i want to display, the my factory method will just be a switch that returns the correct type of control from some static function.

two different factory types for different levels of complexity.

abstract factories are especially used for tokanizers and parsers, while a factory methods occur all over most peoples code without them knowing what it is.
wheneevr you see a method

public function getThing(v:Number):ISomething
{
switch(v)
{
case 0:
return new LittleThing() as ISomething;
break;
case 1:
return new BigThing() as ISomething;
break
}

}

thats a factory (method)!