programming forums Java Java JSRs Mobile Certification Databases Caching Books Engineering OS Languages Frameworks Products This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
Sheriffs:
Saloon Keepers:
Bartenders:

# Case Study On Sales Tax Problem

Jayaraj Jaganathan
Ranch Hand
Posts: 70

I am much interested in applying OOAD to the below problem.
I have completed the solution for the below problem.
Source Code

the above link gives you the source code
I request some one in this fourm to review my design

PROBLEM TWO: SALES TAXES

Basic sales tax is applicable at a rate of 10% on all goods, except books,
food, and medical products
that are exempt. Import duty is an additional
sales tax applicable on all imported goods at a rate of 5%, with no
exemptions.

When I purchase items I receive a receipt which lists the name of all the
items and their price (including tax), finishing with the total cost of the
items, and the total amounts of sales taxes paid. The rounding rules for
sales tax are that for a tax rate of n%, a shelf price of p contains
(np/100 rounded up to the nearest 0.05) amount of sales tax.

Write an application that prints out the receipt details for these shopping

INPUT:

Input 3:
1 imported bottle of perfume at 27.99
1 bottle of perfume at 18.99
1 packet of headache pills at 9.75
1 box of imported chocolates at 11.25

OUTPUT

Output 3:

1 imported bottle of perfume: 32.19
1 bottle of perfume: 20.89
1 packet of headache pills: 9.75
1 imported box of chocolates: 11.85
Sales Taxes: 6.70
Total: 74.68

David Newton
Author
Rancher
Posts: 12617
SalesTax.java:
• Lines 10-12: Redundant comment.
• Lines 15, 17: Constants should be named with all capital letters, with words separated by underscores.
• Lines 26-35: Misleading comment: you use numeric values in the comment that are not defined in the method itself: if the constants change and the comments don't you're misleading the code maintainer.
• Line 19: There's no reason to have this be an instance variable. (See next.)
• Entire class: As written there's no good reason to have this be anything but static methods. If it implemented an interface and there were different ways of calculating the tax I could see it being a class.
• Line 64: Misleading comment; uses values not defined locally.
• Lines 70-75: I'm not a big fan of redefining parameter values; it's potentially misleading and I believe it should be avoided.
• Design: I'm not convinced that an Item should have a sales tax field. Items don't really have sales tax: purchases do (or "line items" do, which is a combination of an item, a quantity, etc.).

• Item.java:
• Getter/setter comments: don't bother; it's obvious.

•
Istvan Kovacs
Ranch Hand
Posts: 100
I'm not good at patterns, but isn't this a case where we should have different classes for the taxes, as their behaviour/applicability differs? Then they could be applied separately. (Would that be the Visitor? Strategy?)

Jayaraj Jaganathan
Ranch Hand
Posts: 70
Thanks for your patient in reviewing my code and giving valuable feed back.

David Newton wrote:SalesTax.java

I have renamed into Tax.java due to requirement changes
Requirement 1
to
Requirement 2

• Lines 10-12: Redundant comment.

• I have removed it

• Lines 15, 17: Constants should be named with all capital letters, with words separated by underscores.

• I have changed it

• Lines 26-35: Misleading comment: you use numeric values in the comment that are not defined in the method itself: if the constants change and the comments don't you're misleading the code maintainer.

• You are right and I have changed it

• Line 19: There's no reason to have this be an instance variable. (See next.)

• I have changed it

• Entire class: As written there's no good reason to have this be anything but static methods. If it implemented an interface and there were different ways of calculating the tax I could see it being a class.

• if i use interface as below

and implemented class say SalesTax . for requirement 1 this holds good
but when requirement changes which need Passport to determine SalesTax.
Even though I program to interface still there is no use, because i am going to change both
Tax.java and implemented class SalesTax.java

• Line 64: Misleading comment; uses values not defined locally.

• I am not clear on this . Please brief

• Lines 70-75: I'm not a big fan of redefining parameter values; it's potentially misleading and I believe it should be avoided.

• Please let me know how do you think this can be solved.

• Design: I'm not convinced that an Item should have a sales tax field. Items don't really have sales tax: purchases do (or "line items" do, which is a combination of an item, a quantity, etc.).

• I too agree and created a class names OrderDetail.java for line item which has an Item and tax .
and Order.java for an Purchace

Item.java:
• Getter/setter comments: don't bother; it's obvious.

•