0

I have read about Factory Method where Sub class creates needed Object and Abstract Factory has methods where concrete classes creates needed Object

Factory Method

public class PizzaStore {

    public Pizza orderPizza(String type) {
        Pizza pizza = createPizza(type);
        pizza.prepare();
        pizza.bake();
        pizza.cut();
    }

    abstract Pizza createPizza(String type);

}

public NewYorkPizzaStore extends PizzaStore {

    public Pizza createPizza(String type) {
        Pizza pizza = null;
        if("cheese".equals(type)) {
            pizza = new CheesePizza();
        }
        else if("onion".equals(type)) {
            pizza = new OnionPizza();
        }

        return pizza;
    }

}

public class pizzaTestDriveByFactoryMethod() {

    public static void main(String args[]) {
        PizzaStore ps =  new NewYorkPizzaStore();
        ps.orderPizza("cheese");
    }

}

Using a Factory

public class NewYorkPizzaFactory extends PizzaFactory {

    public Pizza createPizza(String pizza) {
        Pizza pizza = null;
        if("cheese".equals(type)) {
            pizza = new CheesePizza();
        } else if("onion".equals(type)) {
            pizza = new OnionPizza();
        }

        return pizza;
    }

}

public class PizzaStore {

    PizzaFactory factory;

    public PizzaStore(PizzaFactory factory) {
        this.factory =  factory
    }

    public Pizza orderPizza(String type) {
        Pizza pizza =  factory.createPizza(type)
        pizza.prepare();
        pizza.bake();
        pizza.cut();
        return pizza;
    }

}

public class pizzaTestDriveByAbstractFactory() {

    public static void main(String args[]) {
        PizzaFactory nwFactory = new NewYorkPizzaFactory();
        PizzaStore ps =  new PizzaStore(nwFactory);
        ps.orderPizza("cheese");
    }

}

Same use case implemented using Factory Method and Abstract Factory. Why there should be a FactoryMethod instead of using Abstract Factory or a Utility Factory (Such as Chicago Factory/NewYorkFactory). In which case Factory method is useful on Abstract Method?

Dave Schweisguth
  • 36,475
  • 10
  • 98
  • 121
ksv
  • 37
  • 5
  • Is there a question here somewhere? – Keppil Dec 27 '13 at 11:15
  • I have see the link provided. But I did not understand why should we use factoryMethod instead of using AbstractFactory. – ksv Dec 27 '13 at 11:24
  • You have very similar problem with factories as I do. We both read HF Design Patterns, creational patterns and don't understand them. But to me one more thing is unclear, this is the difference between this two patterns and the simple factory idiom defined in the same chapter of the book (along with it's example SimpleFactory class). At the end of the factory idiom (p.118/119) they say you can substitute SimpleFactory with NYPizzaFactory or ChPizzaFactory - to me this sounds like Abstract Factory? – croraf Jan 02 '14 at 19:08
  • You have the excerpts from HF Design Patterns here http://csc.columbusstate.edu/woolbright/java/factory.html, and link to my question here http://stackoverflow.com/questions/20848082/motivation-for-simple-factory-and-factory-method-pattern. – croraf Jan 02 '14 at 19:10

2 Answers2

1

The main difference is that you can implement a factory object without needing to sub class the object you are processing the factory too. This also means that you can do things like swap factories in the fly. On the other hand if you are just doing something simple or closely coupled then you might as well just provide the method as that is simpler.

Tim B
  • 40,716
  • 16
  • 83
  • 128
  • So, you say AbstractFactory has more advantages on factoryMethod. Then what is the use of factory method over Abstract Factory. – ksv Dec 27 '13 at 12:00
  • 1
    Factory Method is simpler. Abstract (or interface) Factory is more powerful. Use the one you need for your case. – Tim B Dec 27 '13 at 16:42
0

You should ask whether the factory task is conceptually tied to the base class and/or subclasses (like createPizza) or not (like procurePizzaBoxes). The pizza box supplier is not only conceptually distinct, but can be swapped. It might even be one national company supplying pizza boxes to every city.

Another way to do decide is that if you're making subclasses just to implement the factory method, then you'd be better off factoring it out into an abstract factory.

But if the subclasses have their own characteristics and need to exist regardless, and the implementation of the method is tied to them (even if it's procurePizzaBoxes, but the supplier is local and isn't an important detail), then you should use factory method as a natural application of polymorphism and OO, and to keep the class count down.

Refactoring from factory method to abstract factory is probably easier than the reverse, and requires fewer classes, so can be considered the more conservative choice.

Aleksandr Dubinsky
  • 22,436
  • 15
  • 82
  • 99
  • Can you please explain 'But if the subclasses have their own characteristics and need to exist regardless, and the implementation of the method is tied to them' with an example. I cannot think a situation of such sort. – ksv Dec 27 '13 at 14:25
  • @ksv Let's say the PizzaStore subclasses don't simply override orderPizza, but override lots of methods and provide new ones. Perhaps the NewYorkPizzaStore overrides orderGarlicKnots and adds requestMafiaProtection. So instead of having a PizzaStore, a NewYorkPizzaStore, a NewYorkPizzaFactory, and a NewYorkGarlicKnotFactory, use factory methods. This will cut the class count in half. Remember, your goal is readability and maintainability, and "overengineering" by adding lots of extensibility points that you don't (yet) need is counter-productive. – Aleksandr Dubinsky Dec 28 '13 at 11:06