|
Re: Oh No! DTO!
|
Posted: Feb 29, 2004 11:48 AM
|
|
> > Immutable objects have several advantages. You can > cache > > them. You can pass them to methods without making a > copy. > > You can return them to methods without making a copy. > > That's the value (value, get it?) of data-oriented > objects > > that have private methods with getters and setters. > > Do you think you could achieve the same ends with public > final variables that are set in a constructor?
Such a class is also immutable. I don't usually do immutables that way in Java because it's idiomatic to do immutables with private variables and get methods. That's how JavaBeans do it, how exceptions do it, how events do it. That idiom is all over the Java APIs. I tend to use the idioms in a language because I think it helps people read the code. I wouldn't use get methods in C#, for example, I'd use properties. I happen to personally prefer that approach. I like C#'s properties approach better than Java's get methods approach, but I'm somehow not so offended by get methods that I feel the need to avoid them in Java.
On the other hand, if I come into a team as a consultant and they have decided to do immutables with public final variables, then I would do it that way on their project if that's what they wanted. On that project, that's what those people would be used to seeing.
I can't find it now, so I think maybe I never published it. But in one of my interviews with Gosling, he said that for a while in one of the early iterations of Oak (which became Java), he had some kind of properties feature in there. He said everyone he showed it to went, "bleh," so he lost his confidence in it and took it out. He seemed to regret having taken it out at the time I was interviewing him, though, and seemed dissappointed with the JavaBeans get/set method approach that was kind of tacked on later. The get/set approach isn't the best design, perhaps, but it works and is idiomatic and not so much of a burden, so in Java I just use it.
|
|