Factory method pattern: Difference between revisions

Revision as of 08:18, 7 August 2003

Revision as of 12:55, 10 December 2003

Line 1:

A [[software design pattern]] '''factory pattern''' is used for [[computer programming]].

'''See also:''' [[Software design pattern|Design pattern]], [[Abstract factory pattern]], [[ClassFactory]]

Line 7:

=== Factory design pattern in Java ===

The Factory pattern is useful to solve a common [[problem]]: Very often you'll have to construct an [[object]], based on some [[input]], and the functions[[function]]s inside the object will depend upon the input. A good example would be a [[class]] to read [[image filesfile]]s and make thumbnails[[thumbnail]]s out of them. You could, of course, bung them all into one class and have it decide which bit of code to run on its own:

Line 45:

1 - A bad way to design the ImageReader

This [[method]] has the [[advantage]] of abstracting the [[file type]] from the [[class]] that calls this ImageReader, but as the number of file types supported gets larger, the code will quickly become huge, unwieldy and hard to maintain.

Another [[solution]] that seems possible is to have a separate [[object]] for each of these file types:

public Interface ImageReader

Line 94:

2 - Another better, but still not so good way to read images

Again, there are advantages[[advantage]]s to this [[method]] (clean [[organisation]] of the ImageReader classes, split up in several classes), but this is at the [[cost]] of the [[abstraction]] of the image type. Again, when you get to have dozens of file types, this will be unsatisfactory and produce code that is hard to maintain.

So what's the [[solution]]? Simply to take the best of both worlds, by using the Factory pattern (which you should already have an idea of by now). The [[Factory]] is a [[class]] that returns another class depending on the [[context]]. So in this [[situation]], keeping the separate [[class design]] as in the last example:

public class ImageReaderFactory

Line 120:

3 - A good design for the ImageReader: The Factory design pattern

Et voilà! That's all there is to it. The Factory pattern, while not so complex as to be awe-inspiring, is a neat [[solution]] to a [[problem]] that occurs fairly often. Next time you see a situation where you need a different object depending on the [[context]], you'll think of the Factory pattern.

The [[combination]] of a [[type code]] and its associated specific [[factory object]] can be stored in a [[map]]. The [[switch statement]] can be avoided to create an extensible factory by a [[mapping]].