The method toString()
allows you to parse or represent an object in java as a string.
Table of Contents
Without toString()
:
public class Test { public static void main(String [] args) { City s1=new City("Berlin"); City s2=new City("Washington"); System.out.println(s1); System.out.println(s2); } } class City{ String city; City(String city){ this.city=city; } }
Output:
With toString()
:
public class Test { public static void main(String [] args) { City s1=new City("Berlin"); City s2=new City("Washington"); System.out.println(s1); System.out.println(s2); } } class City{ String city; City(String city){ this.city=city; } public String toString(){ //overriding the toString() method return city; } }
Output:
Style
Here are a few rules and pointers that should be known when using toString()
:
- Always override the
toString()
method. - Provide a good
toString()
implementation makes your class much more pleasant to use - When practical, the
toString()
method should return all of the interesting information contained in the object. - Whether or not you decide to specify the format, you should clearly document your in intent in the JavaDoc. The reason why is due to the fact that
toString()
is always public and therefore part of the public interface. Anything that’s a part of the public interface should never change in behavior, if possible. - Provide programmatic access to all of the information contained in the the value returned by
toString()
. (i.e. don’t provide any information solely through thetoString()
method without making it accessible with its own dedicated method). - Know that
toString()
should not:- Make network requests
- Not make new threads or wait on other threads
- Not have changing fields
Using toString()
With @Override
Whenever you are overriding methods, you want to use the @Override
annotation, so that the compiler knows to warn you when you aren’t actually overriding a method- whether because you made a typo or because you’re offering a new argument overload instead of overriding an existing one.
This is how it looks, with an annotation, when overriding the toString()
method:
@Override public String toString() { return "This is an example."; }
When added to the previous example, CityTest.java:
public class Test { public static void main(String [] args) { // Object s1 & s2 is made City s1 = new City("Berlin"); City s2 = new City("Washington"); System.out.println(s1); System.out.println(s2); } } class City { String city; City(String city) { this.city = city; } @Override // This is the Override annotation, tells you that method is overriden public String toString() { // Method Header return city; } }
Notice that when using the @Override
annotation, it just needs to be directly above the method header of the method that is being overridden. Although the annotation is optional, it allows a reader not familiar with the codebase to know that the method exists in the parent class. In the case of the above example program CityTest.java, you would know that the class Object
(Object
is is a built in class, the root of the whole Java class hierarchy. The full name of the class is java.lang.Object
) is the common parent for all Java classes.
Also the @Override
annotation allows for the compiler to throw a warning if you aren’t actually overriding an existing method, which can be caused by:
- The method doesn’t exist in the parent class
- The method name has been misspelled
- The method return type differs from the return type of the method in the parent object
- The parameter count and/or parameter type(s) differ from the method in the parent object
- i.e. you overloaded the method on accident, not overrided as you wanted to.