• Post Reply Bookmark Topic Watch Topic
  • New Topic

Preserve Encapsulation while Displaying Information  RSS feed

 
Andy Rosemond
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Suppose I've got the following class to represent a Car and Tire:



I'm fully aware that my Car and Tire example are lacking notable attributes, but that's not the focus of my question.

From Effective Java(p. 53):

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.
 
Carey Brown
Saloon Keeper
Posts: 3329
46
Eclipse IDE Firefox Browser Java MySQL Database VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Note that these are the same:
 
Andy Rosemond
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Carey Brown wrote:Note that these are the same:


That's fine. I understand that, but is my getter for the Tire bad or wrong?
 
Diego Rauda
Greenhorn
Posts: 4
Java MySQL Database Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi!

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

 
Andy Rosemond
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Diego Rauda wrote:Hi!

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
 
Diego Rauda
Greenhorn
Posts: 4
Java MySQL Database Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Diego Rauda wrote:Hi!

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:

 
Diego Rauda
Greenhorn
Posts: 4
Java MySQL Database Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Andy Rosemond wrote:
Diego Rauda wrote:Hi!

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
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Diego Rauda
Greenhorn
Posts: 4
Java MySQL Database Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am so sorry I ever tried to answer your question.
Bad questions and bad answers are just a symptom of the blind leading the blind! I just realized this.
I am too, deleting my account.
 
Campbell Ritchie
Marshal
Posts: 56598
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!