Is the Decorator Pattern too much for implementing a coffee ordering system?

Question

Update: Since we usually say, "the situation will determine if any Design Pattern is a good fit for the job"... will a coffee ordering system in real life be solved using the Decorator Pattern?

Is the Decorator Pattern too much for implementing a coffee ordering system? The Head First Design Patterns book use it as an example, but I think I would have just used 2 arrays or tables to implement it:

coffee type (for french roast, house blend, etc)
addition (caramel, cream, cinnamon, etc)

so it can be 2 arrays in a prices.php, or 2 tables in the DB, and read into 2 arrays.

When the customer orders the coffee, then the choices will sum up the price.

It looked like using the Decorator Pattern is quite an overkill, or do you think there are good reason to use this pattern actually? As an example, I think it is fine, but it also feel weird if it looks like a real life problem that is total solvable in a simple way but a more complex solution is used instead.

Answer 1

This is a typical problem with examples for higher-level abstractions. The example has to be simple enough to be easily understood and demonstrate the concepts, which also means for a lot of Design Patterns that it's also more easily implemented in another way.

That said, the way I've normally seen Decorators described is in windowing systems. You have a standard window and you want to allow windows to be scrolled horizontally and vertically. You can either subclass the window for all possible variations or you could provide a horizontal scroll-bar decorator and a vertical scroll-bar decorator that performs the task and has the added benefit that you can then decorate other controls as well without having to subclass even more. This (to me) is a perfectly valid use for Decorators that gets the ideas across, but would be much more difficult to provide example code for.

Answer 2

Problem is, there is no particular answer for "would it really be". Depends on the programmer. People coding short examples can come up with any pattern they like, but only when you know the rest of the system can you decide the structure.

I believe that when you give something a name, it becomes a thing that you have to learn, like the trapezium rule - which I think is actually just common sense one you know the field. Don't think of the decorator pattern as a thing that sits by itself as a tool, its just one way of achieving the desired functionally. If a counter class wraps an Integer, is that a decorator pattern, or do we just not care?

Id code it in the most sensible way you can think of, using the Design Patterns as guides/ideas. Try to forget their names - just let learning the patterns improve your programming. (But look them up again before an interview!)

Answer 3

They are trying to teach the concept, not how to create a coffee ordering system. The decorator pattern is used is much more complex situations such as UI.

The decorator pattern could be used in places such as the Java IO system. A BufferedReader is a decorator for a Reader.

This pattern is extremely useful, and there are places where it finds good use.

Answer 4

Like someone else mentioned, the principle being explained can be sort of lost on a simple example required for a book, but in the real world when you program larger more complicated systems, the pattern will be a better choice for maintainability.

I think the point you are missing in the example is that the decorator pattern is about adding behavior. In the headfirst example the behavior is calculating the cost.

Assume that the class is implemented the way you describe, using arrays, and then totaling the cost. That would be fine, you could do it that way and total the cost of the coffee and toppings. But, now say the government implements a heavy tax on coffee because they think caffeine is bad for you and they want people to drink less. Now how are you going to add the tax calculation to the drinks? You definitely don't want to modify the original class because this would violate the open/closed principle. You could also extend the class and add the behavior, but that would mean that you would probably have to extend the class for all foods/drinks in your store that contained caffeine. That would turn into a mess and you would could possibly have a lot of classes to extend. The last option is to use the decorator pattern and add the tax calculating behavior dynamically to anything you want. This would solve the problem without violating the open/closed principle, or the nightmare of extending possibly dozens of classes.

This is what the decorator pattern is about.