RTFJD (the JavaDocs are your friends!) If you haven't read them in a long time, then RRTFJD (they might have changed!)
Stephan van Hulst wrote:A possible exception to this rule are types that serve no other purpose than to represent data that needs to be serialized, such as a class that represents an XML element
Jesse Silverman wrote:
I can't speak for everyone, but when I see something with no constructor, no .equals() and a bunch of getters and setters it indeed makes me ask "What style of coding is this??"
I'm going to be a "small government" candidate. I'll be the government. Just me. No one else.
I'm going to be a "small government" candidate. I'll be the government. Just me. No one else.
At present, I think that is unlikely. A record doesn't usually have a no‑args constructor, nor does it have the annotation seen in this Color constructor.Tim Holloway wrote:. . . I'm not certain that records are fully-interchangeable with legacy JavaBeans. . . .
Campbell Ritchie wrote:[additional]Nor do the getters in a record match the naming convention for Beans.
I'm going to be a "small government" candidate. I'll be the government. Just me. No one else.
That sounds like a good idea. That would obviate one of the potential problems with Beans, the many setXXX() methods.Tim Holloway wrote:. . . popping record support in there might light up a lot of systems all at once.
Stephan van Hulst wrote:Yes, always hide your fields.* You never know if you might want to change the internal representation of your type, and if you expose your fields by making them non-private, you're stuck with them forever.
A possible exception to this rule are types that serve no other purpose than to represent data that needs to be serialized, such as a class that represents an XML element. Seeing as their internals are pretty much already exposed when you serialize them, using getters usually only adds a lot of unnecessary boilerplate. Even then, I often prefer to err on the side of safety and use getters instead of public fields anyway.
*Note that I said "hide your fields" and not "yes, always add getters and setters". Don't blindly add getters for every field that your class consists of, only those that actually need to be exposed. Be even more judicious with setters. Most classes don't need setters at all.
Stephan van Hulst wrote:Yes, always hide your fields.* You never know if you might want to change the internal representation of your type, and if you expose your fields by making them non-private, you're stuck with them forever.
A possible exception to this rule are types that serve no other purpose than to represent data that needs to be serialized, such as a class that represents an XML element. Seeing as their internals are pretty much already exposed when you serialize them, using getters usually only adds a lot of unnecessary boilerplate. Even then, I often prefer to err on the side of safety and use getters instead of public fields anyway.
*Note that I said "hide your fields" and not "yes, always add getters and setters". Don't blindly add getters for every field that your class consists of, only those that actually need to be exposed. Be even more judicious with setters. Most classes don't need setters at all.
Antonio Moretti wrote:the main purpose of using setters is for the validation of values.
However, by making the fields private we also need getter so we can read them if needed. Is this correct?
RTFJD (the JavaDocs are your friends!) If you haven't read them in a long time, then RRTFJD (they might have changed!)
I'm going to be a "small government" candidate. I'll be the government. Just me. No one else.
Jesse Silverman wrote:You could also find that you want to re-factor your object so that one of your data members disappears completely.
The public getter might stay just exactly as it is to the user, but now will be computing that quantity on the fly, or getting it from somewhere else, without disturbing any user code.
Stephan van Hulst wrote:
Antonio Moretti wrote:the main purpose of using setters is for the validation of values.
No, the main purpose of setters is to allow the outside world to change a property of an object. Validation is secondary: You validate because you wrote a setter. You don't write a setter because you want to validate.
I'm going to be a "small government" candidate. I'll be the government. Just me. No one else.
I'm going to be a "small government" candidate. I'll be the government. Just me. No one else.
Antonio Moretti wrote:
But then would it be right to still call such a getter a getter, since it is no longer getting the value of a field, but computing one?
RTFJD (the JavaDocs are your friends!) If you haven't read them in a long time, then RRTFJD (they might have changed!)
Stephan van Hulst wrote:Well, what if I only want to change the width, and not the height? Should I really have to look up the current height and pass it back into the setter, just to ensure it doesn't change?
Antonio Moretti wrote:I was thinking, with setSize(), you no longer refer to the fields by name.
For example, if this was a point, and method was setPosition(), you could change the fields from cartisan (x, y) to polar coodinates (angle, distance) one day and everything would still work.
It just seems to me that having a setter like setWidth() that does nothing other than set the value of a private field (and potentially validate) is questionable.
There is a whole section in Effective Java by Joshua Bloch about that; he calls it, “taking a defensive copy.”Carey Brown wrote:. . . return a copy of the field.
There are at least five different ways you can return a List, four of which behave as a sort of defensive copy. I think the same applies to sets and maps.. . . returning Lists comes to mind as well.
Stephan van Hulst wrote:
Antonio Moretti wrote:I was thinking, with setSize(), you no longer refer to the fields by name.
Why is that important? The caller doesn't know that there are fields with names width and height. The fact that we have an accessor getHeight() is not an admission that it the class also uses a backing field with the name height. Why should we make extra effort to use different property names for our accessors than for our backing fields?
That is an understanding I suspect takes a long time to filter down to learners.Stephan van Hulst wrote:. . . an object should generally not be modifiable at all! . . .
Look up “bean pattern”. The bean pattern is useful in very specific circumstances, and that mandates getXXX() and setXXX() methods called after the fields. The bean pattern is useful for recording the state of GUI components, and a few other instances (we discussed it in the last week in JSF (=Java Server Faces, I think). but it is probably not suitable for general use. Look at my example of honey, where there are two possible implementations each returning the percentage of sugar in the honey. It would probably be more accurate to say that honey contains 3% of “something else”, but I am trying to teach programming not apiculture.Antonio Moretti wrote:. . . we have been taught to name setters and getters after the field names. This is also what IDEs like Netbeans do, if you let them generate the getters and setters automatically . . .
Antonio Moretti wrote:we have been taught to name setters and getters after the field names. This is also what IDEs like Netbeans do, if you let them generate the getters and setters automatically, it always bases them on the field names. For these reasons, I assumed that getters and setters must be named after fields, otherwise, they are not strictly getters and setters, but methods that do something slightly different.
Stephan van Hulst wrote:...If you need to calculate it from other properties, then that is fine too.
RTFJD (the JavaDocs are your friends!) If you haven't read them in a long time, then RRTFJD (they might have changed!)
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |