Overriding toString()
Hi guys,
I was having a debate with a friend about the use of toString() in a datamodel class for rendering (in a tree) purposes.
They wanted to override the toString() method (to return a user friendly name for an object) and call it from the TreeCellRenderer to display to the user.
I feel this is architectually unsound for several reasons:
1. The toString() method does not have to be overriden (it is recommended, but not compulsory), so any child class of the datamodel class will have to override toString() as well, otherwise an incorrect value will be returned to the renderer.
2. Presentation logic is embedded in the datamodel class, breaking the basic rules of MVC, the programmer should derive the renderer's text in the tree cell renderer (to support internationalisation etc.).
Can anyone point me in the direction of any resources / best practices regarding this problem, or just tell me if I am wrong :-)
Sorry if this doesn't make sense, if I have left anything out please say so and I will respond as soon as I can.
Thanks,
Aidos
[1111 byte] By [
Aidosa] at [2007-10-2 1:57:54]
> They wanted to override the toString() method (to
> return a user friendly name for an object) and call
> it from the TreeCellRenderer to display to the user.
>
> I feel this is architectually unsound for several
> reasons:
I think so to. toString shouldn't be part of the application logic.
> Hi guys,
>
> I was having a debate with a friend about the use of
> toString() in a datamodel class for rendering (in a
> tree) purposes.
>
> They wanted to override the toString() method (to
> return a user friendly name for an object) and call
> it from the TreeCellRenderer to display to the user.
>
> I feel this is architectually unsound for several
> reasons:
>
> 1. The toString() method does not have to be
> overriden (it is recommended, but not compulsory), so
> any child class of the datamodel class will have to
> override toString() as well, otherwise an incorrect
> value will be returned to the renderer.
Huh? If they all extend from the same class that actually does the overriding - where's the problem?
> 2. Presentation logic is embedded in the datamodel
> class, breaking the basic rules of MVC, the
> programmer should derive the renderer's text in the
> tree cell renderer (to support internationalisation
> etc.).
Well, good OO would call for a proxy and whatnot, but it usually is overkill. And you have to transfer the data somehow.
> Can anyone point me in the direction of any resources
> / best practices regarding this problem, or just tell
> me if I am wrong :-)
Stick with toString(), IMO. It's practical enough for purposes, and if you use an approach like this
http://www.javaworld.com/javaworld/jw-09-1999/jw-09-toolbox.html
nobody will be able to understand it later...
Though I might add that I'd rather implement a getStringRepresentation() method instead of using toString(), but it boils down to the same.
toString() should not be used to provide data that an application depends on, in general. In general it is for providing a human-readable representation only, for debugging or logging -- for a human to see, not application code.
Well, the contract of toString() says it should return a 'textual representation of the object'. That's all well and good in the general case, but I probably wouldn't use it for objects that need special rendering.
I see toString() as mostly a debug tool.
But you're right, it's the renderer's job to determine what the data should look like, not the model object's.
> But you're right, it's the renderer's job to
> determine what the data should look like, not the
> model object's.
The renderer would be the TableCellRenderer, though. The String is still data. The TableCellRenderer could still work its magic on the String, like loading an Image of the same name or such. Couldn't it? Even if it simply paints the letters of the String to the screen: the String itself is not quite presentation.
I think I should explain my example better, I can't give you the exact example I was working with, but I can contrive something similar.
Say we have a Person object with member fields (as Strings) Title, First Name and Surname (and get/set operations), this object is used in an Address Book.
If the developer overrides the toString() to return m_firstName + " " + m_lastName then we have a string that represents the object for a simple address book.
However, elsewhere in the system I want to display Title Surname, LastName, then the toString() method won't work.
I suppose my argument against this all is that the display for the Person object by using toString() is forced into one representation only, rather than using a renderer to pull out the fields required and display them as appropriate. This is what I mean by presentation logic stored in the datamodel tier (which is only for persistence / business rule validation).
I am really hopless at explaining this example, as I was trying to explain it to my friends at the time, and I obviously didn't explain it too well then :-).
IMO the datamodel layer is there for persistence and business rule validation, and although the fields of the object can be used in the presentation layer, the actual format of the presentation should not be defined at the datamodel layer (due to the example above, I may want more than one representation of the object).
Aidosa at 2007-7-15 19:39:01 >
> I am really hopless at explaining this example, as I
> was trying to explain it to my friends at the time,
> and I obviously didn't explain it too well then :-).
I think you've explained it quite well, and I think others here understand you points as well. Probably your friends aren't as versed in OO principles as my fellow Oligarchs™ here. Here you're discussing. With your friends you're trying to teach. It's a different kind of communication, and teaching is much harder, IMHO.
I'm inclined to agree with you view about not using toString that way. (I admit that I didn't at first, but a bit of pondering and reading the followup discussion convinced me).
One thing you want to be careful of though, is taking it to the extreme that every object exposes every field through a getter. I'm most definitely NOT in the "getters and setters are evil" camp, and in a pure data container class, it's appropriate to expose the state--that's why the thing exists!
But at some point you'll need to strike a balance between letting the renderer pick & choose what to display and how, and not exposing too much of your object's internal state. For me this is still a bit of a black art, and I tend to go with what feels right at the moment.
jverda at 2007-7-15 19:39:01 >
> One thing you want to be careful of though, is taking
> it to the extreme that every object exposes every
> field through a getter. I'm most definitely NOT in
> the "getters and setters are evil" camp, and in a
> pure data container class, it's appropriate to expose
> the state--that's why the thing exists!
>
> But at some point you'll need to strike a balance
> between letting the renderer pick & choose what to
> display and how, and not exposing too much of your
> object's internal state. For me this is still a bit
> of a black art, and I tend to go with what feels
> right at the moment.
Hear hear!
