Sign in to follow this  
civita

Factory method:

Recommended Posts

Hi, I wonder what the difference is between using a factory method and using an abstract factory interface (delegation). Where an "abstract factory interface" means an abstract factory but with just one type of object (not a family). Both will just depend on an interface, but the delegation will enable us to change behaviour/factory at runtime, whereas the inheritance-based factory method is fixed. What is the benefit of mangling the abstract factory interface into the current class which is what the factory method does? Except for less code. Thanks in advance!

Share this post


Link to post
Share on other sites
It means you can write the code for a factory pattern and reuse it. Reusable code means less bugs.

Also the abstract factory paves the way for other patterns such as the pluggable factory where the common interface to a factory allows it to be stored in a dll.

Share this post


Link to post
Share on other sites
Hi,

Thanks for the reply, but..

Maybe I wasn't that clear.

Lets say we have the ordinary factory method:
Pizza-stores seem to be popular ;)

================================================================
Alternative 1, factory method:
================================================================
class PizzaStore
{
abstract Pizza* create()
doOtherStuff()
}

class PizzaStoreA derive PizzaStore
{
Pizza* create() { return new PizzaA; }
}

================================================================

This is fine and good, but instead of fixing this at compile time, we can resort to the delegating alternative which can be changed at runtime:

================================================================
Alternative 2, delegating to an abstract interface:
================================================================
class PizzaStore
{

PizzaFactory theFactory;
Pizza* create() { return thFactory.create() }
doOtherStuff()
}

class PizzaFactory
{
abstract Pizza* create()
}

class PizzaFactoryA derive PizzaFactory
{
Pizza* create() { return new PizzaA }
}
================================================================

If u understand what i mean. Both refer to interfaces and not to actual concrete pizzas. So what is the benefit of mangling the interface into the class as we do in the alternative one, which is a factory method?

Thanks!

Share this post


Link to post
Share on other sites
Because the latter lets you install RegularPizzaFactory, StuffedCrustPizzaFactory, and DeepDishPizzaFactory... or lets you install PizzaHutFactory or DominoesFactory or LittleCaesarsFactory.

Any of those can read general-purpose configuration to further determine exactly which kind of pizza to create... but they might all have incompatible pizza specs (PizzaHut might have a different way of describing the toppings than Dominoes; XML instead of plaintext line-by-line, say), but the configuration sets themselves are compatible (octet-stream; plain ol' bytes).

Each factory can then implement its own configuration specs, and handle creation of its own pizzas... so long as what it produces are subclasses of Pizza when all is said and done.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this