Abstract Factory as a Strategy?

Question

I would like to know whether it is possible to use an abstract factory as a strategy, e.g. nesting the two patterns and call the factory class a strategy as well.

I provided an example to illustrate my question. The class ShoppingMall would be the context class, while PizzaStore would be the abstract factory in question I would consider to be a strategy in this case as well.

// interface of context class, mostly a wrapper
// uses 3 different strategies
interface ShoppingMall
{
    PizzaStore GetPizzaStore();
    ParkingLot GetParkingLot();
    Adverts GetAdverts();

    void CustomerArrives();
}

// abstract factory & strategy interface?
interface PizzaStore 
{
    Pizza CreatePizzaCheese();
    Pizza CreatePizzaVeggie();
    Pizza CreatePizzaClam();
    Pizza CreatePizzaPepperoni();
}

// strategy interface
interface ParkingLot 
{
    void Pay();
}

// strategy interface   
interface Adverts
{
    void CreateSpam();
}

class PizzaStoreChicago implements PizzaStore {}
class PizzaStoreNY implements PizzaStore {}
class PizzaStoreObjectVille  implements PizzaStore {}

class ParkingLotBig   implements ParkingLot {}
class ParkingLotSmall implements ParkingLot {}
class ParkingLotCheap implements ParkingLot {}

class AdvertsAnnoying implements Adverts {}
class AdvertsBoring implements Adverts {}
class AdvertsStupid implements Adverts {}

class ShoppingMallObjectVille implements ShoppingMall {}
class ShoppingMallJavaRanch implements ShoppingMall {}
class ShoppingMallAverage implements ShoppingMall {}
class ShoppingMallOther implements ShoppingMall {}

If it solves the problem you need to solve, go with it. Patterns are just a name for common solutions to common problems. You use them as you want to solve your problems. — JB Nizet, Jul 11 '12 at 07:50
This is not about whether it solves the problem (which it does). I want to know if the terminology of strategy and abstract factory pattern can be applied to the same class in cases like this one. — red_rain, Jul 11 '12 at 07:54

score 2 · Accepted Answer · answered Jul 11 '12 at 07:53

Yes, there is no harm in combining more then one design pattern to get a problem fixed. from your design, I can see the following problems:

The interface PizzaStore should not have all those creational methods as it does not really make sense (you are forcing all pizza stores to implement all those methods and what if a pizza store makes only veggie pizza?). A Strategy pattern says your have to have one method or abstract algorithm implemented in many different ways. This will give your the flexibility to switch algorithms and strategies at runtime.

The ´PizzaStore´ should rather look like this:

interface PizzaStore 
{
    Pizza CreatePizza();
}

All PizzaStore implementations should then implement a CreatePizza method that will return a Pizza which should be an abstract class or an interface. Implementations/extensions of the Pizza should then be: PizzaCheese, PizzaVeggie, PizzaClam, PizzaPepperoni

Thanks for pointing out the Pizza issue, missed that one. I derived the example from a more complex design where the abstract factory creates related objects of different classes. I chose the pizza store because I like Head First: Design Patterns. Should have used `dough`, `sauce` and `toppings` instead to illustrate that. — red_rain, Jul 11 '12 at 08:20

Abstract Factory as a Strategy?

1 Answers1