What are the pros and cons of the decorator pattern?

Question

I'm reading this article:

http://www.codeproject.com/Articles/479635/UnderstandingplusandplusImplementingplusDecoratorp

I'm thinking of implementing this pattern in a school project. It's not a requirement so I can half-ass it. But, I just thought it would be a good opportunity to expand my knowledge and expertise.

The school project is this: Create a pizza ordering application where employees enter the orders of customers. So a pizza, and it can have any number of toppings.

The above article (and the description from the Head First: Design Patterns book) seem to match my application perfectly.

Here is my issue: This doesn't seem like a good pattern, and here is why:

Whenever "pizza place" adds a new topping to their menu.... they will have to add a whole new class, and recompile their ordering systems and re-distribute them?

I think perhaps the issue is that all of the examples I google have to deal with food and toppings of some sort.

1. Am I just finding the wrong types of examples for this pattern?
2. What are some better examples where this pattern would be implemented?
3. Is the food industry one of them and it is just the implementations that are screwy?
4. Is this one of those patterns that is out there but is hardly ever used in actual production code?

Answer 1

Actually Decorator allows you to add some behavior without recompiling source code. You can declare IPizza interface in your pizza domain, and use this abstraction in your application. Then you can add another assembly, which will have other implementations if IPizza decorators, and inject those implementations to your application with dependency injection. Thus you will not need to recompile neither your application, nor domain.

BTW Adding new class is better, than modifying existing classes. You always can break something what was working before your modifications. That's why Single Responsibility Principle was introduced.

Another your questions:

1. No, you are finding good examples of Decorator pattern usage (especially one in Head First book). Also take a look on IO Stream class and it's decorators for inspiration.
2. Pattern just should solve problem. If you don't have problem, which pattern is targeting, than it's just wrong usage of pattern.
3. Patterns do not stick to industry. They stick to problems of your code (often its about duplication of code)
4. No, it's good pattern. Think again about Streams in .Net. Is it production code?

Answer 2

Generally in real world applications you will be dealing with more abstract objects (ie not things liek pizzas and coffees :))

A real world example of Decorator pattern is the Java BufferedReader class. It adds additional functionality to a FileReader for example.

The benefits are that you can change behaviour at runtime and you are not tied down to having many many different objects.

In your example, if I have four objects:

Pizza
Tomatoes
Cheese
Mushrooms

Then I can build a pizza with any combination of the four ingredients. Otherwise I would have to have a ton of classes to allow that behaviour e.g. PizzaWithTomatoesAndCheese, PizzaWithTomatoesAndMushrooms