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.
- Am I just finding the wrong types of examples for this pattern?
- What are some better examples where this pattern would be implemented?
- Is the food industry one of them and it is just the implementations
that are screwy? - Is this one of those patterns that is out there but is hardly ever used in actual production code?
Actually Decorator allows you to add some behavior without recompiling source code. You can declare
IPizzainterface in your pizza domain, and use this abstraction in your application. Then you can add another assembly, which will have other implementations ifIPizzadecorators, 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: