Factory design pattern
Author
I''m having difficulty understanding the factory design pattern. Or should I say, I don''t understand the point of using it.
Can someone please explain why it is used, preferably with a simple example?
Think of it like this. C++ is a statically-typed language, which means it requires you to state the type of a variable at compile-time. Sometimes, though, that is too early, and you won''t have all the information you need to decide what type a variable should be until run-time, possibly through some source external to the program. When you encounter such a situation, there are various ways of virtualising object creation, and many such techniques fall under the heading of "creational patterns".
An example might be a drawing program. Imagine the user can select shapes from a toolbar, and then place the shapes onto a canvas. When the shape is placed, the program has to look to see what the toolbar selection was before it can decide what type of object to create. So, if you have a class hierarchy like this:
Then, when you create the actual shape, you might have logic like this:
There''s a couple of problems with this: the logic has to be repeated in any part of your program which can create a shape, which means multiple points that have to be synchronised when changes are made, and the if-else chain is likely to be long and unreadable for a real-world program.
The way we solve these problems is to spin-off the shape creation logic into a function or class, and then hide it out of the way. That gives the benefit of making the creation point clearer (you don''t have an if-else chain shoved in your face), and means you only have one point of maintenance when you want to add new shape selections. So, you might do this:
Now whenever you want to create a shape, the code will look like this:
In this example, create_shape is a creational pattern known as "virtual constructor". Factory patterns are simply variations on a theme of object creation. You should Google for "factory method" and "abstract factory" to find out more.
An example might be a drawing program. Imagine the user can select shapes from a toolbar, and then place the shapes onto a canvas. When the shape is placed, the program has to look to see what the toolbar selection was before it can decide what type of object to create. So, if you have a class hierarchy like this:
class Shape{public: // ...stuff... virtual ~Shape() =0 {} // make Shape an abstract class};class Circle : public Shape{};class Rectangle : public Shape{}; Then, when you create the actual shape, you might have logic like this:
Shape *shape;if(toolbar_selection == circle) shape = new Cirle;else if(toolbar_selection == square) shape = new Square;else if(...) // ... There''s a couple of problems with this: the logic has to be repeated in any part of your program which can create a shape, which means multiple points that have to be synchronised when changes are made, and the if-else chain is likely to be long and unreadable for a real-world program.
The way we solve these problems is to spin-off the shape creation logic into a function or class, and then hide it out of the way. That gives the benefit of making the creation point clearer (you don''t have an if-else chain shoved in your face), and means you only have one point of maintenance when you want to add new shape selections. So, you might do this:
Shape* create_shape(ShapeID id){ Shape *shape; if(id == circle) shape = new Cirle; else if(id == square) shape = new Square; else if(...) //...}; Now whenever you want to create a shape, the code will look like this:
Shape* shape = create_shape(toolbar_selection); In this example, create_shape is a creational pattern known as "virtual constructor". Factory patterns are simply variations on a theme of object creation. You should Google for "factory method" and "abstract factory" to find out more.
Author
Thank you for that excellent description. I have recently purchased the design patterns book but I find the vocabulary very confusing.
I have a followup question: :-) In another thread "Object Factory Quetion", there is a discussion about registering a class. Why would you need to register a class? Is it a facility so that the factory class does not have to hard code the classes it can produce in "if/then" statements?
I have a followup question: :-) In another thread "Object Factory Quetion", there is a discussion about registering a class. Why would you need to register a class? Is it a facility so that the factory class does not have to hard code the classes it can produce in "if/then" statements?
quote:Original post by Mnsr ColaYes. One can add new classes without touching the factory, and then call the factory to create a class given its ID. Look up for pluggable factories.
Why would you need to register a class? Is it a facility so that the factory class does not have to hard code the classes it can produce in "if/then" statements?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
