Meaningless Drivel is fun!*
The moose likes Java in General and the fly likes Case Study On Sales Tax Problem Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Case Study On Sales Tax Problem" Watch "Case Study On Sales Tax Problem" New topic
Author

Case Study On Sales Tax Problem

Jayaraj Jaganathan
Ranch Hand

Joined: Jun 29, 2009
Posts: 70

I have completed reading HF OOAD.

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
baskets...

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

Joined: Sep 29, 2008
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

    Joined: May 06, 2010
    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

    Joined: Jun 29, 2009
    Posts: 70
    Thanks for your patient in reviewing my code and giving valuable feed back.

    Please look into my new Design as per your comment



    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

    Please give your valuable comments on this

  • 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.

  •  
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Case Study On Sales Tax Problem