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.
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.