Whether or not you specify the format, provide programmatic access to all of the information contained in the value returned by toString.

In my Car class, the toString() method will obviously return the name, and according to Effective Java, as quoted above I should provide a getter as well. My problem is when returning the details of the Tire.

Question:

Given the advice quoted from Effective Java, how would I properly return the details of my car including the Tire for display purposes?

Would I do this:

In the Car class:

Or to put it another way, when you have a class, in my case(Tire), that is also an attribute of another class, in my case(Car), when returning the details to be printed in a GUI, how would I do so and perverse encapsulation?

This question comes from the many different definitions that you can find from searching and reading, mostly on StackOverflow.

Well, first of all, you need to specify the object type of the second argument being passed to the Tire constructor:

Now, since you have specified that:

You don´t need to keep referring to the brand and type variables you are using within the methods of this this class as this.brand and this.type.

Finally, your toString is just a little excesive and is missing a print. Like someone pointed out, you can just do type.toString() in order to parse the object TireType into a String. As for the print, do:

Well, first of all, you need to specify the object type of the second argument being passed to the Tire constructor:

Sorry about this, I quickly created this example in notepad++.

TireType is an Enum

Sorry, I just realized you don´t actually want to print,but instead you want to do a JTextField.setText(parsed_variable). In that case, just the type.toString shall do!

Andy Rosemond

Ranch Hand

Posts: 35

posted 3 months ago

Okay fine, but it doesn't at all answer my question.

I don't really understand this forum. I left SO because I wasn't really getting the help I need, I come here and damn, all I'm getting are responses about data parsing. What next, Junilu Lacar is going to come along and give his "advice" about my code being code smell, go off topic, and never really give an answer. It took him 3 posts from another user to finally say that getters for display were fine!

Well, to hell with him, this forum. I'm done with this board, and to the admins that run this wreck, delete my account. I regretted I created this account.

Maybe the two other posters won't be back, but in case somebody else finds this discussion:-
Yes, you should provide a getTyre method, as Bloch explains in the reference cited. Otherwise anybody wanting details of the tyre will have to parse the String which is difficult, and if the exact details change, creates brittle code. A simple change from commas separating values to pipes separating tokens can cause dependent code to crash.
But what if the tyre is a mutable object? What if it is possible to change its details?To avoid this problem, if the tyre is mutable, is to take a defensive copy both when receiving the Tyre reference into the constructor and when returning it from a get method.Would you have a setTyre() method? Probably yes; after all changing tyres is something we do in real life. In which case the setTyre method should also take a defensive copy, as well as verifying that the tyre is the right size.
The same applies for tyre sizes as for a tyre type enum, but an enum is probably easier to use because its elements default to being immutable.