• Post Reply Bookmark Topic Watch Topic
  • New Topic

method value keeps changing...  RSS feed

 
tom jenkins
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, I'm just having some trouble trying to figure out why the value of my method changes when I try to use it in for instance the Overwritten toString method..

for example.. grossPay() returns 500 when i test it, but then when i test it on the toString method it returns 1100...

I had a similar problem with the overtime() method when writing the body of my grossPay, but i fixed it by saving the return value to a double "hoursovertime".

I tried doing something similar for my toString method.. but when i save grossPay to a double it all comes out right, but then overtime() returns 120 instead of say.. 40 like it should.. and if i erase the variable it goes back to normal "40" but then grossPay is 1100 again.... I tried to save overtime() into a variable also but no cigar it stayed at 120...

any idea why my method return values are changing?? can someone help me fix it please??

 
Campbell Ritchie
Marshal
Posts: 56581
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why are you using DecimalFormat rather than the % tags? String#format can be used just like system.out.format in that link, and you don’t need to mess about with decimal format.
Why are you using super. so frequently? You don’t need it. If your superclass has a public getID() method, then this class has inherited it and you can simply call getID().
Your two constants ought to be static because they are the same for every instance of that class.
When you calculate the overtime, are you resetting count to 0? [It ought to be 0.0, really.] Otherwise you are liable to pay two weeks’ worth of wages if you run the program twice
 
Seetharaman Venkatasamy
Ranch Hand
Posts: 5575
Eclipse IDE Java Windows XP
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
other side, money calculation on double is sin.
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A few more comments, mostly about names and how they help clarify your code or mislead you/others:

1. Is this code really about an employee? Isn't it more about how pay is calculated? Wouldn't something like WeeklyPay be a better name for it? "A WeeklyPay object knows how to calculate the pay for a weekly-paid employee." makes a lot more sense if you try to state the responsibility of this class. True, "WeeklyEmployee" probably makes about as much sense in that sentence but I still assert that the employee is not the focus of the code, it's the pay. Also, the calculation of overtime pay is a matter of policy and employees don't normally set or enforce policy.

2. I would prefer names like: OVERTIME_RATE over OVERTIMES, MAX_REGULAR_HOURS over LIMIT. Campbell was right, these should be static final. I would also prefer hoursWorked over count

3. Campbell already suggested you get rid of your the DecimalFormat variables but ignoring that for just a second and talking about names: there is really nothing that helps you distinguish between a dec, deci, and decix. Names like that are just a product of laziness on the programmer's part, frankly. No offense but how much harder would it have been to think up RATE_FORMAT and PAY_FORMAT? These are much more expressive and don't make me bounce my eyes back and forth between the declarations and the usage.

4. Like Seetharaman said, don't use doubles when working with money values; you'll get floating point errors.

5. Lastly, try to make methods as short and sweet as possible. The idea is to write code that has "Cohesion (computer science)". It may take a while for you to develop the skill of recognizing which things are related vs together but strive to learn the difference. Here's a version of your code that's more cohesive (and coherent):


Notice that each calculation has been separated out into a separate method to make the code more cohesive. Granted, the BigDecimal operations make the code slightly less readable than if normal arithmetic operators were used but that's a limitation of the language that we all just have to deal with for now. You might ask if this is really better, what about the explosion of one-liner methods... isn't that a waste? Waste in what? The time it takes for a person to understand and maintain a program is much more lengthy/valuable/costly than the time it makes to make a few more method calls. It's not like there's a limit to the number of methods you can write in a Java program, right? And who cares if the method only has one line? Some of the best developers in the world consistently write methods that are shorter that 10 lines of code, many of them just one-liners like the ones above. It's all about cohesion and coherence.

This goes a step beyond beginning Java, I know, and into Object-Oriented design concepts but if you want to be a good OO programmer, you should also learn about good OO design and techniques. You should also learn about unit testing; learn how to use JUnit. It will make testing and designing your programs a lot easier.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!