|
In [[computer programming]], the '''factory pattern''' is a [[software design pattern]]. The factory pattern is useful to solve the common problem of constructing [[object (computer science)|objects]] based on some [[input]] such that [[function (programming)|function]]s inside the objects depend upon the input.
A [[software design pattern]] '''factory pattern''' is used for [[computer programming]].
==Example==
=== Factory design pattern in Java ===
TheConsider Factory pattern is useful to solve a common problem: Very often you'll have to constructas 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. YouThis could,can ofbe solved course,by bundlebundling them all into one class and have it decidedeciding which bit of code to run on its own:
===A bad solution===
public class 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. ▼ 1 - A bad way to design the ImageReader
===A better, but not perfect, solution===
▲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 {
}
Again, there are advantages to this [[method ]] (clean organisation of the ImageReader classes, the code being 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 need to be supported, this will be unsatisfactory and produce code that is hard to maintain. ▼ 2 - Another better, but still not so good way to read images
===Using the factory pattern===
▲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.
SoThe what'sfactory thepattern solution?can Simplybe used instead to takecombine the bestbetter parts of both worlds, by using the Factory pattern (which you should already have an idea of byabove now)solutions. The [[Factory]]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 {
}
The [[combination ]] of a [[type code]] and its associated specific [[factory object]] can be stored in a [[ map (computer science)|map]]. The [[switch statement]] can be avoided to create an extensible factory by a [[mapping]]. ▼ 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==
| 