Archived

This topic is now archived and is closed to further replies.

Mnsr Cola

Factory design pattern

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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:


  
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
quote:
Original post by Mnsr Cola
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?
Yes. 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.

Share this post


Link to post
Share on other sites