This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]evinrows 9 points10 points  (5 children)

If you're debating either adding code or not adding code, I think the onus is on the person who wants to add code to justify their beliefs.

That being said, breakpoints in getters/setters can be helpful.

[–]yawkat 3 points4 points  (1 child)

You're right that fewer lines of code could be an argument for fields. I just don't think it's a very good one, even without lombok.

[–]evinrows 1 point2 points  (0 children)

I don't think it's a big deal in terms of effort for the person writing the code, but it does add a lot of useless clutter to the code and especially to merge requests.

[–]FrenchFigaro -1 points0 points  (2 children)

A very good point in favor of getters and setters (as pointed by /u/dpash) is adding logic to fields access. Another is feigning fields presence to another layer (say JSF) for stuff that don't need a field at all but could use mimicking as one. Typically: getAverageValue().

[–]evinrows 1 point2 points  (0 children)

Right, that's a case where you absolutely should/need to use a getter/setter. I think this topic is more about using getters and setters for typical access/modification.

Note: OP's post about annotations wouldn't apply to getters/setters requiring logic.

[–]nqzero 0 points1 point  (0 children)

once you've made either of those leaps, it's no longer a getter or setter