A Little More Detail
Figure 14-2 showed the basic structure of the case study. Figure 15-1 shows this structure in more detail. Here, I show that the SalesOrder object uses a SalesTicket object to print a sales ticket.
Figure 15-1. SalesOrder using SalesTicket.
As you saw in Chapter 14, SalesOrder uses a CalcTax object to calculate the tax on the order. To implement the printing function, SalesOrder calls the SalesTicket object, requesting that it print the ticket. This is a fine, reasonably modular design.
In the process of writing the application, suppose I get a new requirement to add header information to the SalesTicket.
How can I handle this new requirement? If I am writing the system to be used by just one company, it may be easiest simply to add the control of headers and footers in the SalesTicket class. This is shown in Figure 15-2.
Figure 15-2. SalesOrder using SalesTicket with different options.
In this solution, I have put the control in SalesTicket, with flags saying whether it is to print the headers or the footers.
This works quite well if I do not have to deal with a lot of options or if the sales orders using these headers do not change.
If I have to deal with many different types of headers and footers, printing only one each time, then I might consider using one Strategy pattern for the header and another Strategy pattern for the footer.
What happens if I have to print more than one header and/or footer at a time? Or what if the order of the headers and/or footers needs to change? The number of combinations can quickly overwhelm.
In situations like this, the Decorator pattern can be very useful. Instead of controlling added functionality by having a control method, the Decorator pattern says to control it by chaining together the functions desired in the correct order needed. The Decorator pattern separates the dynamic building of this chain of functionality from the client that uses it, in this case, the SalesOrder.