0

As part of my AP curriculum I am learning java and while working on a project I wondered which of the following is best way to return a value?

   public double getQuarters(){
    return quarters;
}

or

     public void getQuarters(){
    System.out.println(quarters);
}

***Note: I now that the second option is not "technically" returning a value but its still showing my the value so why bother?

  • Go with the common sense option. It is best to learn when the need arises. When the need presents itself common sense will again guide you to the correct option. – necromancer Sep 26 '13 at 01:27

6 Answers6

2

Your answer would be correct. The second method doesn't return any value at all, so while you might be able to see the output, your program can't. The second method could still be useful for testing or even for a command line application, but it should be named something like printQuarters instead.

John Zeringue
  • 705
  • 3
  • 13
1
 public double getQuarters(){
    return quarters;
}

Use this incorder to encapsulate quarters and hide it from being accessed by other programs. That means, you have to declare it as private quarters. Let see the second option:

 public void getQuarters(){
    System.out.println(quarters);
}

However, this seems wrong as getQuarters is not returning anything. Hence it would make more sense to refactor it as

     public void printQuarters(){
         System.out.println(quarters);
     }
Andromeda
  • 1,370
  • 2
  • 10
  • 15
  • Depending on its relevance with respect to the rest of the object, I'd likely put that in the `toString()` method. But kudos on recognizing that the method should reflect what the purpose is. – Makoto Sep 26 '13 at 00:49
1

You answered your own question. For most definitions of the word "best", you should go with the first option.

Your question, however, does touch on the object-oriented programming topic of accessors and mutators. In your example, "getQuarters" is an accessor. It is usually best to use accessors to retrieve your values. This is one way to adhere to the Open/Closed Principle.

Also, the Java community has a coding convention for this and many tools and libraries depend on code following those conventions.

Carlos Macasaet
  • 1,176
  • 7
  • 23
0

If all you need to do is display the value when this method is called, and you are ok with console output, then your System.out.println method will do the job. HOWEVER, a function that actually returns the variable is much more semantically correct and useful.

For example, while you may only need to print the variable for your current project, what if you came back later and decided that you were instead going to output your variable to a file? If you wrote your getQuarters function with a println statement, you would need to rewrite the whole thing. On the other hand, if you wrote the function as a return, you wouldn't need to change anything. All you'd have to do is add new code for the file output, and consume the function where needed.

A returning function is therefore much more versatile, although more so in larger code projects.

ElliotSchmelliot
  • 7,322
  • 4
  • 41
  • 64
0

You return values to a specific point in your program, so that the program can use it to function.

You print values at a specific point in your program, so that you as an end user can see what value you got back for some function.

Depending on the function - for instance, yours - the result of quarters is no longer regarded in the program; all it did was print a value to the screen, and the application doesn't have a [clean|easy] way to get that back to use it.

If your program needs the value to function, then it must be a return. If you need to debug, then you can use System.out.println() where necessary.

However, more times than not, you will be using the return statement.

Makoto
  • 104,088
  • 27
  • 192
  • 230
0

Option 1 is far superior.

  1. It can be easily Unit Tested.
  2. What if the spec changes and sometimes you want to print the result, other times put it into a database? Option 1 splits apart the logic of obtaining the value from what to do with it. Now, for a single method getQuarters no big deal, but eventually you may have getDimes, getEuros, etc...
  3. What if there may be an error condition on quarters, like the value is illegal? In option 1, you could return a "special" value, like -1.0, or throw an Exception. The client then decides what to do.
user949300
  • 15,364
  • 7
  • 35
  • 66
  • 1
    I am not a TDD fanatic, but TDD teaches that a focus on unit testing is _never_ premature. – user949300 Sep 26 '13 at 01:32
  • well, CLEARLY we have a counter example here! ;-) sorry, just kidding in this comment. this is an agree to disagree situation but i just had to backup my rather strong opinion in this context with a downvote. – necromancer Sep 26 '13 at 01:34
  • The Stackoverflow voting and scoring has been bugging me lately, sometimes what I think is a bad, or merely an o.k. answer gets a lot of upvotes, etc. But I never imagined that an answer favoring code that is easier to test would _ever_ get a downvote. I'm quite stunned. – user949300 Sep 26 '13 at 06:24
  • well, i wouldn't give it any weight because it is just the opinion of some stranger. just think of it as a personal opinion rather than an objective judgement. in this case it is my opinion is that what you said is not wrong but it is just the wrong time to bring it up when a beginner is struggling to even comprehend the notion of a return value! a smaller part of my opinion is against the treatment of TDD as dogma. a lot of stunningly good + useful code has been and is still written in a non-TDD way. i. e. TDD doesn't offer the sort of advantage that a symbolic langauge offers over assembler. – necromancer Sep 26 '13 at 06:43
  • in sum, if it weren't the very first point of your answer i would have felt no reason to offer my 2 cents with a downvote. please treat this constructively or dismissively, but please don't take it as a slight. – necromancer Sep 26 '13 at 06:46