3 ms·

> “This isn’t idiomatic. Please rewrite this code without the class keyword”. I’ve seen people people make a face like I just had their child expelled from kind

> “This isn’t idiomatic. Please rewrite this code without the class keyword”. I’ve seen people people make a face like I just had their child expelled from kindergarten. Lol true Don't forget all the getters and setters merely updating/reading a variable Python says "explicit is better than implicit" but Java goes too far with it, and in the most verbose/inflexible ways possible

Izkata 3y ago
> Don't forget all the getters and setters merely updating/reading a variable > and in the most verbose/inflexible ways possible 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 (such as transforming the value because a different representation was more useful internally; particularly useful for libraries). Python has @property to maintain that interface if need be, but these Java conventions started when no such thing existed in the language. I haven't done Java in a long time, so I don't know if it has it even now..
- klibertp 3y ago
  > these Java conventions started when no such thing existed in the language. Is there language support for these in the newer Java versions (I'm not up to date with newer features, since I won't be able to use them on Android anyway)? The reason for these getters/setters is as you said: a workaround for the language deficiencies. It's true for quite a few patterns, and it's not unique to Java; you get similar (in nature) patterns emerging in all languages. Greenspun's tenth rule and all that. What's problematic is porting these workarounds wholesale to languages that don't have the limitations that originally led to their creation. In Kotlin, for example, every property has an implicit getter and setter, by default - you can override either easily with a dedicated syntax. In that case, insisting on writing explicit methods for getters and setters is simply a misuse of the language. Same in Python, as you note, where you can replace direct access to object attribute with a property without changing the user-facing interface of a class. I think JS also developed a feature like this? It's kind of impressive the OO languages managed to get this so wrong for so long, even though Smalltalk got it right in the 70s...
  - cultureswitch 3y ago
    I think it's strange that people complain about the verbosity and boilerplate getters and setters in Java when this is entirely a non problem, provided your code is well designed. If your class has any setter function, you're doing OO wrong. Mutating an object should 1) only happen if you have a very good, inescapable reason; 2) never be exposed directly to code outside the class, including children. If your class must have a mutating function, it should be a high level operation, not "set". If it really is "set" then that implies the field being set isn't a part of that object in any real sense. A well designed class might have a couple of getters, but the inclusion of getters is a deliberate decision to allow client code to see the internal state. In other words, blame the IDEs for the idea of auto-generating getters and setters. The language itself did a decent job of protecting class state.
    - kazinator 3y ago
      OOP is routinely used with stateful, mutating objects; it has been hailed as a good way to manage that paradigm. If mutation is bad, so most objects don't mutate, you're talking about a functional niche in OOP, not mainstream OOP. A class may need a setter function for some boring, pragmatic reason like, say: - the language doesn't have keyword parmeters: constructors have only positional parameters - the class has a large number of properties. - most users set only a small subset of the properties, defaulting the rest. (And you can't easily predict which subsets are popular enough to get their own constructor variants.) In that situation you might want to just construct the object in two steps: default everything and set a few selected properties (and then don't touch them). It's de facto immutable, just not around construction time.
    - raverbashing 3y ago
      I almost agree with you, I don't agree with the gatekeeping/nitpicking of saying "you're doing it wrong" But I do agree that in most cases you don't need to call individual setters. And especially not automatically create one for every variable in your class
- raverbashing 3y ago
  No, it's not extra functionality, it's a crutch > being able to override the getter/setter in a subclass I think even C++ can do this without an explicitly named getter/setter > and keeping a consistent interface so users don't need to change how it's called Just use a better language > Python has @property to maintain that interface if need be Exactly. Java is unjustifiably limited in this regard
  - ttflee 3y ago
    When you are coding a dynamic library, and providing consistent ABI between versions is a thing, you could appreciate this. Perhaps you may also appreciate PImpl/D_PTR etc.
- josephg 3y ago
  > 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.
  - Izkata 3y ago
    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.
    - josephg 3y ago
      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.

Izkata 3y ago

> Don't forget all the getters and setters merely updating/reading a variable > and in the most verbose/inflexible ways possible 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 (such as transforming the value because a different representation was more useful internally; particularly useful for libraries). Python has @property to maintain that interface if need be, but these Java conventions started when no such thing existed in the language. I haven't done Java in a long time, so I don't know if it has it even now..

klibertp 3y ago
> these Java conventions started when no such thing existed in the language. Is there language support for these in the newer Java versions (I'm not up to date with newer features, since I won't be able to use them on Android anyway)? The reason for these getters/setters is as you said: a workaround for the language deficiencies. It's true for quite a few patterns, and it's not unique to Java; you get similar (in nature) patterns emerging in all languages. Greenspun's tenth rule and all that. What's problematic is porting these workarounds wholesale to languages that don't have the limitations that originally led to their creation. In Kotlin, for example, every property has an implicit getter and setter, by default - you can override either easily with a dedicated syntax. In that case, insisting on writing explicit methods for getters and setters is simply a misuse of the language. Same in Python, as you note, where you can replace direct access to object attribute with a property without changing the user-facing interface of a class. I think JS also developed a feature like this? It's kind of impressive the OO languages managed to get this so wrong for so long, even though Smalltalk got it right in the 70s...
- cultureswitch 3y ago
  I think it's strange that people complain about the verbosity and boilerplate getters and setters in Java when this is entirely a non problem, provided your code is well designed. If your class has any setter function, you're doing OO wrong. Mutating an object should 1) only happen if you have a very good, inescapable reason; 2) never be exposed directly to code outside the class, including children. If your class must have a mutating function, it should be a high level operation, not "set". If it really is "set" then that implies the field being set isn't a part of that object in any real sense. A well designed class might have a couple of getters, but the inclusion of getters is a deliberate decision to allow client code to see the internal state. In other words, blame the IDEs for the idea of auto-generating getters and setters. The language itself did a decent job of protecting class state.
  - kazinator 3y ago
    OOP is routinely used with stateful, mutating objects; it has been hailed as a good way to manage that paradigm. If mutation is bad, so most objects don't mutate, you're talking about a functional niche in OOP, not mainstream OOP. A class may need a setter function for some boring, pragmatic reason like, say: - the language doesn't have keyword parmeters: constructors have only positional parameters - the class has a large number of properties. - most users set only a small subset of the properties, defaulting the rest. (And you can't easily predict which subsets are popular enough to get their own constructor variants.) In that situation you might want to just construct the object in two steps: default everything and set a few selected properties (and then don't touch them). It's de facto immutable, just not around construction time.
  - raverbashing 3y ago
    I almost agree with you, I don't agree with the gatekeeping/nitpicking of saying "you're doing it wrong" But I do agree that in most cases you don't need to call individual setters. And especially not automatically create one for every variable in your class
raverbashing 3y ago
No, it's not extra functionality, it's a crutch > being able to override the getter/setter in a subclass I think even C++ can do this without an explicitly named getter/setter > and keeping a consistent interface so users don't need to change how it's called Just use a better language > Python has @property to maintain that interface if need be Exactly. Java is unjustifiably limited in this regard
- ttflee 3y ago
  When you are coding a dynamic library, and providing consistent ABI between versions is a thing, you could appreciate this. Perhaps you may also appreciate PImpl/D_PTR etc.
josephg 3y ago
> 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.
- Izkata 3y ago
  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.
  - josephg 3y ago
    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.