4 ms·

This is strange advice. There's no real drawback from using getter/setter and there are obvious benefits. And even if you mostly use public properties, there w

This is strange advice. There's no real drawback from using getter/setter and there are obvious benefits. And even if you mostly use public properties, there will still be cases where you'll need getter/setter so you'll end up with a messy mix of getter/setter and public properties. Better be consistent and always use getter/setter.

LandR 9y ago
Getters, yes. I would argue that everything that can be immutable should be immutable though unless you have good reason for it to be mutable.
- MrBuddyCasino 9y ago
  Thats the right answer. Have immutable classes with constructor-injected fields, and getters. In Java Lombok makes this scalable to many members using the builder pattern, and in Kotlin its a non-issue anyway.
- davewritescode 9y ago
  Agreed but immutability can lead to builders and builders lead to lots of code bloat. Plus, from what I've experienced lots of frameworks depend on java bean conventions (i.e. getters/setters for everything). There's really two missing features of java that could solve 90+% of the use cases for getters/setters. - Attributes: annotation or keyword based directives for the compiler to generate getters/setters for a given instance variables - Default + named parameters which would reduce a lot of the pain of multiple constructors and constructors with a tremendous number of parameters.
  - phkahler 9y ago
    Instead of attributes that lead to creation of getters/setters, how about the simple notion of private or public access to members? I'm not sure which should be the default, but it sounds like Java programmers would like them private unless otherwise specified. Why add code when all you want is to restrict access?
  - TheSleeprAwakns 9y ago
    Lombok (https://projectlombok.org https://projectlombok.org) exists and takes care of the attribute issue you mentioned.
- ecshafer 9y ago
  You can use setters that return a reference to a new object with the updated says, using some copy and delete mechanism for immutability.
frou_dh 9y ago
If one is commanding an object to set a private data field which one somehow knows the name of, then it's not an object that is being dealt with, just a procedural programming data bag. Setter methods are 95% the same as direct mutation of encapsulated state. It degrades the concept of objects being smart independent entities.
- spdionis 9y ago
  Getters/setters vs public properties has nothing to do with encapsulation. Obviously not all properties are public/have getters and setters.
  - frou_dh 9y ago
    I didn't mention getters at all. I agree that encapsulation status remains constant in the presence of either setter methods or direct mutation, i.e. broken.
- rhapsodic 9y ago
  > It degrades the concept of objects being smart independent entities. "Smart independent entities"? That's a new one on me. What does that mean?
  - frou_dh 9y ago
    An object graph operating more like a network of tiny special-purpose computers with I/O (messages/method-calls). Rather than occupants that are conscious of being not much more than rectangles in a single memoryspace. Alan Kay also made analogies with cell biology.

LandR 9y ago

Getters, yes. I would argue that everything that can be immutable should be immutable though unless you have good reason for it to be mutable.

MrBuddyCasino 9y ago
Thats the right answer. Have immutable classes with constructor-injected fields, and getters. In Java Lombok makes this scalable to many members using the builder pattern, and in Kotlin its a non-issue anyway.
davewritescode 9y ago
Agreed but immutability can lead to builders and builders lead to lots of code bloat. Plus, from what I've experienced lots of frameworks depend on java bean conventions (i.e. getters/setters for everything). There's really two missing features of java that could solve 90+% of the use cases for getters/setters. - Attributes: annotation or keyword based directives for the compiler to generate getters/setters for a given instance variables - Default + named parameters which would reduce a lot of the pain of multiple constructors and constructors with a tremendous number of parameters.
- phkahler 9y ago
  Instead of attributes that lead to creation of getters/setters, how about the simple notion of private or public access to members? I'm not sure which should be the default, but it sounds like Java programmers would like them private unless otherwise specified. Why add code when all you want is to restrict access?
- TheSleeprAwakns 9y ago
  Lombok (https://projectlombok.org https://projectlombok.org) exists and takes care of the attribute issue you mentioned.
ecshafer 9y ago
You can use setters that return a reference to a new object with the updated says, using some copy and delete mechanism for immutability.

frou_dh 9y ago

If one is commanding an object to set a private data field which one somehow knows the name of, then it's not an object that is being dealt with, just a procedural programming data bag. Setter methods are 95% the same as direct mutation of encapsulated state. It degrades the concept of objects being smart independent entities.

spdionis 9y ago
Getters/setters vs public properties has nothing to do with encapsulation. Obviously not all properties are public/have getters and setters.
- frou_dh 9y ago
  I didn't mention getters at all. I agree that encapsulation status remains constant in the presence of either setter methods or direct mutation, i.e. broken.
rhapsodic 9y ago
> It degrades the concept of objects being smart independent entities. "Smart independent entities"? That's a new one on me. What does that mean?
- frou_dh 9y ago
  An object graph operating more like a network of tiny special-purpose computers with I/O (messages/method-calls). Rather than occupants that are conscious of being not much more than rectangles in a single memoryspace. Alan Kay also made analogies with cell biology.