You are a programmer for the software development group of a large retailer. Your company has grown dissatisfied with its current point-of-sale software because it has historically struggled with the correct application and calculation of sales tax on an order. Your business deals primarily with storefront business and its customers are primarily on foot in the store when they buy, so it is of the utmost importance that sales tax be calculated quickly and accurately. This may sound like a simple task, but remember that sales tax varies by state and maybe even by item within that state.

Your supervisor has asked you to pull apart the initial version of a possible new sales system, which he has colorfully but aptly named SaleBad for the sake of illustration (and perhaps his love of Tarzan movies). After a quick analysis, you sketch out the following UML diagram to describe it.

It is clear that the program does, indeed, need some work. To demonstrate the problems within the project, you prepare a brief demonstration of its weaknesses.

Task 1: Highlight the Problems. Unzip and open the project SaleBad. Create some Item objects, a Sale object, and some SaleLines objects (via the addItem method in SaleBad). Determine how the total (from the SaleBad object) is calculated and explain why the class needs to be redesigned. In one or two paragraphs, explain why the current design will not suffice. For the moment, do not worry about how, exactly, that redesign will happen.

It occurs to you that the code needs to be more loosely coupled. Changes in tax policy on various items, or on the tax rate itself, should affect as few classes and methods as possible. As you begin to conceptualize the new design, your supervisor pops his head around the corner again. Evidently, the store has been errantly charging sales tax on food items that are specifically supposed to be tax-free in some states.

You decide that the Item class is the best place to implement sales tax because the tax on each item could vary. The state in which the Item is purchased may also affect the tax, so with these thoughts in mind, you sketch out a new-and-improved UML class diagram, illustrated below.

This diagram is implemented in the project SaleBetter. Despite the improvements, however, something is bothering you.

Task 2: What's Bothering You? You had good reasons to implement tax calculations within the Item class-it makes much more sense than placing it in the other current classes. However, it simply makes more sense to introduce an entirely new Tax class. In 1-2 paragraphs, explain why, citing principles of good program design.

Now that you have decided that the taxation policies on items should be handled in a completely separate class, you proudly craft the UML diagram below. Feeling more and more confident, you implement it in a project called SaleEvenBetter.

Task 3: Taxation With Class Representation. Open the SaleEvenBetter project and explore how sales are calculated. In 1-2 paragraphs, explain how this design improves upon its predecessor.

One final hurdle needs to be cleared before you can mark this project complete: You still need to account for Items that are not taxed. You sketch the UML diagram below, splitting the Tax class into two subclasses, PercentageTax and NoTax. You have a plan in place, and your supervisor approves, so it is time to implement it.

Task 4: Let Them Eat (Untaxed) Cake. Using the project SaleEvenBetter as a starting point, implement the new design as described in the UML diagram above. Verify that the tax method within PercentageTax returns the same value as the getPriceWithTax method in the current version of SaleEvenBetter for taxed items, whereas the tax method in NoTax returns a value of zero. To complete Task 4, submit the new version of SaleEvenBetter.