tags:

views:

166

answers:

7

I've seen both approaches used but have never heard that one way is preferred over the other for any particular reason.

public String toString() {
  return this.field1 + " " + this.field2;
}

versus

public String toString() {
  return getField1() + " " + getField2();
}

I used String concatenation in my example to keep the code brief.

+5  A: 

Use getters, if you have them!

Maybe, one day you change the code so that a getter will not only return the fields value but do something more or create the result in a different way. Then you'll be more then happy that you used getters consistently.

But as usual, there are excemptions from my advice - what do you expect from the toString() method if you allow overriding of the getter methods, do you want it use the classes fields or the result of the - maybe override - getter method.

So, as usual, it depends, but I'd use getters unless I have a good reason to access the fields directly.

Andreas_D
+1  A: 

Using getters in toString is an overkill. And you should not be using toString for non debug purposes.

David Soroko
Re: "And then you should not be using toString for non debug purposes." - what?
danben
there are many instances where using toString() is valid outside of debug purposes. For example if you have an XML class, it is perfectly reasonable to expect .toString() to return a String representation in XML. Same with URL or URL classes, toString() would be the reasonable non-astonishing method expected to provide a String representation of the object.
fuzzy lollipop
Or, every other class. There is a reason that `toString()` is a member of the `Object` class.
danben
Why the downvotes? @danben and @fuzzy: Read the Javadoc for Object.toString(). It doesn't guarantee anything. You don't have to override it. So if your toString() calls anything else's toString, you never know what you might get. 3rd party API's can change this stuff on a whim. If I was generating an XML string my method would be called toXmlString. If you're going to represent an object as a string to an end user, there are all sorts of things to consider: Language, Security/Permissioning, Display Preferences, etc. You put all that logic in toString?
z5h
Why is using getters in toString() an overkill? Most modern compilers are smart enough to inline such calls for optimization purposes
Mihir Mathuria
@z5h: No, you don't have to override `toString()`, but it is recommended. The main reason for this is that `toString()` is called by `System.out.println`. See Effective Java, item 9 for a full description.
danben
@fuzzy lollipop said " For example if you have an XML class, it is perfectly reasonable to expect .toString() to return a String representation in XML". I am interested in an example from some non home grown API. Can you show me one (from SAX, DOM etc...) ?
David Soroko
I can not really improve on z5h 's reply. I assumed that it was common knowledge that toString() should not be used for applicative output.
David Soroko
+3  A: 

Using accessor methods might be preferred if they provide any additional logic on top of just returning the field's value (like uppercasing a string, or something like that). If your class is designed to be extended, I would tend towards accessors because they may be overridden.

danben
I usually make my POJOs/TOs `final`. I also have rarely seen any additional logic going on in a getter.
Adeel Ansari
Really? I have seen getters that generated values that were not even explicit properties of the object in question.
danben
Also, if you have an object that is `final`, then that clearly does not fall under "designed to be extended".
danben
+1  A: 

Do you have any reason to use getter methods? Do they do anything interesting?

...Or are you just using them to expose internal data without actually making the fields themselves public (poor man's encapsulation)?

If the former, then yes by all means use them here as well! If the latter, then it doesn't matter - you might want to use them anyway, just in case you ever give them a real purpose, but it won't make one bit of difference otherwise.

Hackles
+1  A: 

I would prefer to the approach to access the private variables directly. IMHO the gettter methods increase the clutter.

sateesh
A: 

using String.format("%s %s", this.getField1(), this.getField2()); would be the best way to do this, becuase the .getXXX() methods might have logic in them that you want like converting NULL references into empty strings or some default value that you would not get by just blindly accessing the private instances. It is the safest way to do it, just in case someone comes along and adds logic to a .getXXX() method and they don't think to update the .toString() implemenation.

fuzzy lollipop
A: 

If your class has getters and setters for fields, you should be consistent throughout the implementation of that class in whether you use getters and setters or access the fields directly. It doesn't generally make sense to mix levels of abstraction. Otherwise, how can you rationalize using them in some places but not in others? In addition, if there is ever a change in how the getters are implemented, you could end up with subtle bags. toString() is part of the implementation, so it should be consistent as well.

In terms of performance, it shouldn't matter - your trivial getters and setters should be final methods anyway, so they should be inlined anyway. IF they're not final, you should ask yourself why and probably avoid accessing the fields directly unless this is really what you mean to do.

Uri