3 ms·

Curious question — why do people insist so much on fields being private and there being getters and setters, even when all that getters do is return the field a

Curious question — why do people insist so much on fields being private and there being getters and setters, even when all that getters do is return the field and all that setters do is set it? What kind of problem does this arrangement solve? Why not just use public fields?

blacktriangle 6y ago
This protects you from changes to the internal representation of state in the future. Direct field access totally blows away encapsulation.
- grishka 6y ago
  So, uh, do a usage search before changing stuff? You'll have to, anyway.
  - kaba0 6y ago
    Not necessarily agree with private fields, but that is not an option for library writers.
  - erik_seaberg 6y ago
    That works if your class is never used outside your own organization, but the API of published code needs to be changed more gracefully using semver.
highwind 6y ago
Only argument I heard, not that I agree but, is future proofing by abstraction. What if a simple getter evolves into something more complex. Then You'd have to refactor all the places where it was using the fields. I personally never had to do this so I'm not sure if this is a real benefit.
dragonwriter 6y ago
Depending on the language, getters and setters may not be source and/or binary compatible with fields from the client side, so if you might ever need to refactor to a nontrivial getter or setter (whether because you are changing representation or for other reasons), starting with trivial getters/setters instead of fields limits future breakage.
legerdemain 6y ago
I had the same question -- why accessor methods instead of making the fields public, but final. If anything, it seems like a layer of indirection. The only answer that makes any sense is this one from Brian Goetz.[1] Namely, that it's a workaround to support mutable fields of otherwise immutable objects. To be honest, allowing you to override the methods on an immutable, auto-generated class to inject custom accessor logic feels like an immediate retreat from the conceptual goal of providing an immutable record implementation in the first place. [1] https://stackoverflow.com/questions/66702223/why-do-java-records-have-accessor-methods-instead-of-public-final-fields/66704373#comment117935348_66704373 https://stackoverflow.com/questions/66702223/why-do-java-rec...
- skinkestek 6y ago
  > why accessor methods instead of making the fields public, but final. The best explanation I have is that it is: - a convention that seemed like a good idea for many people at the time, it even has a name: Javabeans - it allows for a standard non magic way to add logic to be run when reading or updating fields - in a time where source control tools and Java refactoring tools where not as developed as they are today it made sense to make getters and setters everywhere since changing from public fields to accessor methods after it were already in use was probably scary for large teams.
  - legerdemain 6y ago
    Thanks for your speculation, but I'd rather take Brian Goetz's word for it. He is, after all, one of the architects of the Java language and the records feature in particular. ...Unless you're Brian Goetz's alt account?
    - skinkestek 6y ago
      > Unless you're Brian Goetz's alt account? I have a policy of saying whether if is true or false. That said you should take his word for why it was designed that way and my word as an historical account of why I did that in 2005-2015.
jorblumesea 6y ago
getters and setters prevent other objects from modifying internal properties in unexpected ways. Having that encapsulation and abstraction is important for maintainable code. Also, getters and setters don't always modify individual values. Imagine a class where we have: private val firstName private val lastName fun returnFullName(): return firstName + lastName
- grishka 6y ago
  > modifying internal properties in unexpected ways Except I'm talking about Java classes that store data. They don't do any operations on it, they don't have any internal state, they're more like C structs. > Also, getters and setters don't always modify individual values. Of course. But one doesn't contradict the other.
brabel 6y ago
I think I can answer that... it's all to do with a grand view that the Java original designers had about what objects should look like, in what became known as Java Beans. There's a spec[1] and everything. They wanted to be able to write framework code that could introspect Java beans and expose them directly in a user interface, amongst other things, allowing users to modify them, create them, delete them and even compose them to create their own applications... they had even imagined there could be marketplaces where you could _buy_ Java beans to add to your program, or even to modify your other beans to give them extra power... getters and setters were part of that - they needed to know how to obtain and change the state of an Object, but how the Object internally handled such state changes were up to the Object itself (what we now call encapsulation)... this was similar to how Smalltalk worked and that was an inspiration for the Java beans specification... all this never really turned out the way they wanted, of course, but have a read of the Java beans spec to get a better idea of what they had in mind if you don't fully understand it yet. With time, people forgot completely about Java beans, but for whatever reason, getters and setters sticked around to this day. Many Java developers today think Java beans are just classes with a bunch of getters/setters and never probably heard of PropertyChangeListener, VetoableChangeListener and the other parts of the Java beans spec (some of it lives on in Swing). If you write Java today and just want to expose some data, yeah, just go with public fields if you can't use Java 16 records yet... if you ever need to change how you internally store information, just refactor that to a setter if you really must (it will never happen). [1] https://www.oracle.com/java/technologies/javase/javabeans-spec.html https://www.oracle.com/java/technologies/javase/javabeans-sp...
lowbloodsugar 6y ago
Freedom to change.
ivan_gammel 6y ago
In modern Java they can be used to create an accessor function, because Java still does not have syntax for referencing fields in this context. items.stream().map(Foo::bar) vs items.stream().map(i -> i.bar)
fnord77 6y ago
Magic beans. They were supposed to automagically populate inside a java UI (applet?). seriously, I think the reason is so you could override the getter to do something else, like compute a value and return it... but in practice this almost never happens.

blacktriangle 6y ago

This protects you from changes to the internal representation of state in the future. Direct field access totally blows away encapsulation.

grishka 6y ago
So, uh, do a usage search before changing stuff? You'll have to, anyway.
- kaba0 6y ago
  Not necessarily agree with private fields, but that is not an option for library writers.
- erik_seaberg 6y ago
  That works if your class is never used outside your own organization, but the API of published code needs to be changed more gracefully using semver.

highwind 6y ago

Only argument I heard, not that I agree but, is future proofing by abstraction. What if a simple getter evolves into something more complex. Then You'd have to refactor all the places where it was using the fields. I personally never had to do this so I'm not sure if this is a real benefit.

dragonwriter 6y ago

Depending on the language, getters and setters may not be source and/or binary compatible with fields from the client side, so if you might ever need to refactor to a nontrivial getter or setter (whether because you are changing representation or for other reasons), starting with trivial getters/setters instead of fields limits future breakage.

legerdemain 6y ago

I had the same question -- why accessor methods instead of making the fields public, but final. If anything, it seems like a layer of indirection. The only answer that makes any sense is this one from Brian Goetz.[1] Namely, that it's a workaround to support mutable fields of otherwise immutable objects. To be honest, allowing you to override the methods on an immutable, auto-generated class to inject custom accessor logic feels like an immediate retreat from the conceptual goal of providing an immutable record implementation in the first place. [1] https://stackoverflow.com/questions/66702223/why-do-java-records-have-accessor-methods-instead-of-public-final-fields/66704373#comment117935348_66704373 https://stackoverflow.com/questions/66702223/why-do-java-rec...

skinkestek 6y ago
> why accessor methods instead of making the fields public, but final. The best explanation I have is that it is: - a convention that seemed like a good idea for many people at the time, it even has a name: Javabeans - it allows for a standard non magic way to add logic to be run when reading or updating fields - in a time where source control tools and Java refactoring tools where not as developed as they are today it made sense to make getters and setters everywhere since changing from public fields to accessor methods after it were already in use was probably scary for large teams.
- legerdemain 6y ago
  Thanks for your speculation, but I'd rather take Brian Goetz's word for it. He is, after all, one of the architects of the Java language and the records feature in particular. ...Unless you're Brian Goetz's alt account?
  - skinkestek 6y ago
    > Unless you're Brian Goetz's alt account? I have a policy of saying whether if is true or false. That said you should take his word for why it was designed that way and my word as an historical account of why I did that in 2005-2015.

jorblumesea 6y ago

getters and setters prevent other objects from modifying internal properties in unexpected ways. Having that encapsulation and abstraction is important for maintainable code. Also, getters and setters don't always modify individual values. Imagine a class where we have: private val firstName private val lastName fun returnFullName(): return firstName + lastName

grishka 6y ago
> modifying internal properties in unexpected ways Except I'm talking about Java classes that store data. They don't do any operations on it, they don't have any internal state, they're more like C structs. > Also, getters and setters don't always modify individual values. Of course. But one doesn't contradict the other.

brabel 6y ago

I think I can answer that... it's all to do with a grand view that the Java original designers had about what objects should look like, in what became known as Java Beans. There's a spec[1] and everything. They wanted to be able to write framework code that could introspect Java beans and expose them directly in a user interface, amongst other things, allowing users to modify them, create them, delete them and even compose them to create their own applications... they had even imagined there could be marketplaces where you could _buy_ Java beans to add to your program, or even to modify your other beans to give them extra power... getters and setters were part of that - they needed to know how to obtain and change the state of an Object, but how the Object internally handled such state changes were up to the Object itself (what we now call encapsulation)... this was similar to how Smalltalk worked and that was an inspiration for the Java beans specification... all this never really turned out the way they wanted, of course, but have a read of the Java beans spec to get a better idea of what they had in mind if you don't fully understand it yet. With time, people forgot completely about Java beans, but for whatever reason, getters and setters sticked around to this day. Many Java developers today think Java beans are just classes with a bunch of getters/setters and never probably heard of PropertyChangeListener, VetoableChangeListener and the other parts of the Java beans spec (some of it lives on in Swing). If you write Java today and just want to expose some data, yeah, just go with public fields if you can't use Java 16 records yet... if you ever need to change how you internally store information, just refactor that to a setter if you really must (it will never happen). [1] https://www.oracle.com/java/technologies/javase/javabeans-spec.html https://www.oracle.com/java/technologies/javase/javabeans-sp...

lowbloodsugar 6y ago

Freedom to change.

ivan_gammel 6y ago

In modern Java they can be used to create an accessor function, because Java still does not have syntax for referencing fields in this context. items.stream().map(Foo::bar) vs items.stream().map(i -> i.bar)

fnord77 6y ago

Magic beans. They were supposed to automagically populate inside a java UI (applet?). seriously, I think the reason is so you could override the getter to do something else, like compute a value and return it... but in practice this almost never happens.