> It's actually extra flexibility meant for two things: being able to override the getter/setter in a subclass, and keeping a consistent interface so users don't need to change how it's called if there was a refactor that adds something to the getter/setter
This always strikes me as any-benefit mentality thinking. I agree there is some small marginal benefit to this pattern, but the cost (in time, decreased readability and lines of code) is massive. The benefit of being able to change your getters and setters later in a public interface almost never actually shows up.
Most getters and setters aren’t even part of a public interface anyway - because either they’re private or they’re in application code. In both of these cases, you can delay replacing a public class field with public getters and setters until you actually need to. When it actually provides value, it’ll take all of 5 minutes to do the refactor. Intellij can probably do it instantly. And, Spoilers: this will almost never come up in practice. Public fields are almost always fine.
It was originally for libraries that were distributed as jar or class files without the original source, that crept into general "best practices". Also IntelliJ didn't even exist in the 90s when this started.
It exist now. And even before intellij and eclipse had automated refactoring tools, it was like a 5 minute refactor. Just change your public field to be private, add getters and setters then play whack-a-mole mechanically fixing all the compiler errors that showed up.
I can see the argument for putting them in APIs exposed in jar or class files without the source. But the tasteless trend of adding getters and setters everywhere just looks to me like cargo culting. Its sheep programmers leading other sheep. You can tell its cargo culting because if you questioned anyone about the practice they would always ultimately justify their actions by saying "oh, I just do it because everyone else does it".
I believe its the responsibility of every engineer to decide for themselves what they think beautiful code should look like. You get some pointless arguments, sure, but the alternative is always a mess.
I agree with the cargo-culting, but the person I originally replied to seemed to think there was never any point, and that's what I was replying to - there was a reason it started.
This always strikes me as any-benefit mentality thinking. I agree there is some small marginal benefit to this pattern, but the cost (in time, decreased readability and lines of code) is massive. The benefit of being able to change your getters and setters later in a public interface almost never actually shows up.
Most getters and setters aren’t even part of a public interface anyway - because either they’re private or they’re in application code. In both of these cases, you can delay replacing a public class field with public getters and setters until you actually need to. When it actually provides value, it’ll take all of 5 minutes to do the refactor. Intellij can probably do it instantly. And, Spoilers: this will almost never come up in practice. Public fields are almost always fine.