Java Reference
In-Depth Information
wrap either a component object or another decorator. Sharing the same interface allows decorators
to decorate the base component or another decorator. With a proper implementation, it is simple
to call all relevant function implementations in order from the last decorator to the inner target
component object. In most cases, it should not be difi cult to adapt an existing system to use the
decorator pattern.
The decorator pattern is one of the structural patterns described in the topic of GoF. Its purpose
is to wrap a target object so that you can dynamically add new responsibilities at run time. Each
decorator can wrap another one, which allows for a theoretically unlimited number of decorating of
target objects.
Although this runtime behavior is much more l exible than inheritance via subclassing, it introduces
a level of complexity to concrete subclassing as it makes it more difi cult to determine the types and
behaviors of objects prior to executing the application.
Decorators are used in almost all languages and all platforms, from the UI to the back end.
Most frameworks and run times use the decorator pattern to add l exibility and runtime-specii c
In Java EE, you implement the decorator pattern without boilerplate code. However, unlike the
majority of the patterns in this topic, you often add XML coni guration to the bean.xml .
Several years ago, we won a contract to complete a food and drinks ordering and
payment system for a company that then provided it as a point of sale (POS) service
to its clients. 3 These clients were restaurants, cafés, and bars. We had no knowledge
of the domain, so we made some reasonable assumptions based on the limited
knowledge and information we had at the time. Luckily, most assumptions worked
out well.
One of our design rules was that if an add‐on option changes the price of a
product, it should be added as a new product. So if the restaurant serves extra
portions for an additional price, a new item should be added to the menu.
However, if an option like extra cheese was free, that information could be added
as a side note to the order.
This rule had worked well for every client until one day we met with a café owner
whose business operated slightly differently. T he café was focused on selling
deserts, but it also offered pizza as a savory option. Pizza was the only meal item
on the whole menu. Because the café didn't specialize in pizza, it did not offer
set pizzas but instead let its customers create their own pizzas from a long list of
toppings, and it charged for each topping. This was quite a sensible way for the
café to offer its customers pizza because only a few of its customers would want
Search WWH ::

Custom Search