Factory method pattern: Difference between revisions

Revision as of 23:27, 28 February 2004

Revision as of 11:18, 20 March 2004

Line 1:

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

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

from [http://www.mode-x.com/index.php?id=24 mode-x.com] (contributed by author):

=== Factory design pattern in Java ===

The Factory pattern is useful to solve a common [[problem]]: Very often you'll have to construct an [[Object (computer science)|object]], based on some [[input]], and the [[function]]s inside the object will depend upon the input. A good example would be a [[class (computer science)|class]] to read [[image file]]s and make [[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 20 ⟶ 16:

// Figure out what type of file this input stream represents

// (eg gif, jpeg, png, tif, etc )

FileType = file_type;

decodeFile();

}

Line 43 ⟶ 39:

}

}

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 (computer science)|object]] for each of these file types:

public Interface ImageReader

Line 79 ⟶ 76:

String filename = args[0];

ImageReader out;

if( endsIndotgif( filename ) )

{

Line 88 ⟶ 85:

out = (ImageReader)new JpegReader( file_input_stream );

}

printOut( out.getDecodedImage );

}

}

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

Again, there are [[advantage]]sadvantages 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 103 ⟶ 101:

{

int ImageType = figureOutImageType( is );

switch( ImageType )

{

Line 118 ⟶ 116:

}

}

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]].

==See also==

* [[Software design pattern|Design pattern]]

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

==Reference==

from* [http://www.mode-x.com/index.php?id=24 mode-x.com] (contributed by author):