Factory method pattern: Difference between revisions

Revision as of 05:51, 14 September 2004

Revision as of 18:29, 22 September 2004

Line 3:

=== 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 (programming)|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, bungbundle them all into one class and have it decide which bit of code to run on its own:

Line 84:

Again, there are advantages 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 {