1

I'm confused about the behavior I should expect from a client when thinking about design patterns. To be more precise, I'm reading the Head First Design Patterns book, and on the difference between the abstract factory and the factory method pattern, it explains that by using a factory method, we don't have full control on the "ingredients" used in the "Pizza"s produced in our factories. Here are some pseudo-code snippets to clarify this contrived example a bit more:

public abstract class PizzaStore{
  public Pizza orderPizza(string type){
    Pizza pizza = createPizza(type);
    pizza.prepare();
    //...
    pizza.box();
  }
protected abstract Pizza createPizza(string type);
}

Now each subclass has the opportunity(responsibility) to define the createPizza method as they wish. Pizza is an abstract class either, and the clients extend it and define their pizzas as they wish. Of course we don't have control on the ingredients used in Pizzas by those who extend it.

But then, when it comes to the abstract factory, this is the interface used for ingredients:

public interface PizzaIngredientFactory {
  public Dough createDough();
  public Sauce createSauce();
  //...
}

and this is how a specific type of Pizza will use it:

public class CheesePizza extends Pizza {
  PizzaIngredientFactory ingredientFactory;
  public CheesePizza(PizzaIngredientFactory ingredientFactory)
    this.ingredientFactory = ingredientFactory;
  }
  void prepare() {
    System.out.println(“Preparing “ + name);
    dough = ingredientFactory.createDough();
    sauce = ingredientFactory.createSauce();
    //...
  }

Now an NYPizzaIngredientFactory can be sent to the CheesePizza to make it NYish! But... What if they don't? How do we know that the client of our code will use this CheesePizza in the createPizza method? I think we have no control over it. Or even what if we provide an abstract factory and the user implements a factory method and once again use their own ingredients? For example, What if client creates a ChicagoPizzaStore by extending the PizzaStore, and then for implementing the createPizza method they use a factory method? Have we forced them to use our abstract factory by any means that I'm missing?

They can circumvent using the "ingredients" factories we have made for them, they could even be unaware of this feature(abstract factory) we have provided for them unless they peek at our code. I feel lost in this. A client is the one who uses our code but I think I need to know more about how I should look at it and know what I should have in mind about them that matters the most in case of design patterns. (Sorry for probable English grammar mistakes, Thanks).

Edit_ I think it's also worth mentioning where the confusion originally began. It was after reading this line in the book: "How are you going to ensure each franchise is using quality ingredients?". The pattern seems not like a real constraint on the client, actually.

  • Your question appears to be concerning interface definition, documentation and access control not design patterns. I suggest you familiarise yourself with this. Your description of context is good, but your question/difficulty is rather unclear. docs.oracle.com/javase/tutorial/java/IandI/interfaceDef.html – Martin Spamer Sep 26 '18 at 10:01
  • @MartinSpamer Thanks I had a really hard time choosing a title and choosing the tags for my question too. Is that link explaining interfaces? But I [think I] know what interfaces are. One great benefit of them for example is, that they are abstract and multiple concrete classes can be type-hinted using a single interface, thus adding new classes, the program will still be capable of accepting and using them. Anyways that's a great link I'll take a deeper look at it for sure. But for this question, maybe I should have chosen a better title. – Moytaba Sep 26 '18 at 10:10
  • You'd use the abstract factory pattern over the factory method pattern for options and flexibility, ultimately. This includes the flexibility to completely disregard the ingredient factory. If you're allowing the client to implement the second half of this pattern, you're allowing them full flexibility but you're also losing control over what you can guarantee. What precisely do you need to enforce that you feel you can't with this pattern? – Neil Sep 26 '18 at 10:13
  • @Neil Abstract factory is cool no doubts, we have provided everything the client might need and every region(for example different OSs) can have families of [related] classes. But my confusion originally began when I read these lines in the book: "How are you going to ensure each franchise is using quality ingredients?". But as far as I can understand from this pattern, it is more of a "facilitator" rather than a "preventer". Maybe those lines are just for the sake of making the book more funny, I have no idea. – Moytaba Sep 26 '18 at 10:21
  • @Narnia Right, this is offering flexibility, not constraints. The constraints you'll have to add on your own, either by obliging specific types to be passed or by using another pattern such as Builder pattern which would let you better define how an object is made. – Neil Sep 26 '18 at 10:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.