Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Case Study On Sales Tax Problem

 
Jayaraj Jaganathan
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.

  •  
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic