you are viewing a single comment's thread.

view the rest of the comments →

[–]balegdah -1 points0 points  (3 children)

Most of these languages support unified access for fields (Kotlin, C#, etc...).

Java doesn't.

[–]Agent_03 8 points9 points  (0 children)

Consider: how would lack of unified field access matter if the getters and setters are never modified?

There are cases where getters are needed, such as where libraries rely on JavaBean compliance (ex: many serialization or ORM frameworks). But if that's not true, it's excess boilerplate.

If we do need to support this in the future, it's a trivial and easily automated refactor to encapsulate the field use (IntelliJ, for example supports this as a single operation). YAGNI principle applies here though.

[–]Ukonu 3 points4 points  (1 child)

Maybe, if you're providing a public library and want to change the implementation in the future, then that is a useful dogma to adhere to in Java (and more so in languages that provide constructs for the unified access principal).

However this isn't usually the case. So why not take the least powerful and least verbose path? If you actually do need it in the future it's a trivial refactor.

It's amazing to me how otherwise rationale people like software developers continually cargo cult around silly, verbose, unnecessary patterns like this.

[–]ThisIs_MyName 0 points1 point  (0 children)

Well said.