Avoid getters and setters whenever possible

Re:Avoid getters and setters whenever possible by laurent123456 on Thursday March 22, 2018 @06:44AM (#16647436)

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.

[ Parent | on HN ]

Re:Avoid getters and setters whenever possible by LandR on Thursday March 22, 2018 @06:47AM (#16647448)

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.

[ Parent | on HN ]

Re:Avoid getters and setters whenever possible by davewritescode on Thursday March 22, 2018 @08:03AM (#16647830)

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.

[ Parent | on HN ]

Re:Avoid getters and setters whenever possible by phkahler on Thursday March 22, 2018 @08:19AM (#16647934)

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?

[ Parent | on HN ]

Re:Avoid getters and setters whenever possible by TheSleeprAwakns on Thursday March 22, 2018 @12:34PM (#16650187)

Lombok (https://projectlombok.org) exists and takes care of the attribute issue you mentioned.

[ Parent | on HN ]

Re:Avoid getters and setters whenever possible by MrBuddyCasino on Thursday March 22, 2018 @07:55AM (#16647783)

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.

[ Parent | on HN ]

Re:Avoid getters and setters whenever possible by ecshafer on Thursday March 22, 2018 @08:11AM (#16647881)

You can use setters that return a reference to a new object with the updated says, using some copy and delete mechanism for immutability.

[ Parent | on HN ]

Re:Avoid getters and setters whenever possible by frou_dh on Thursday March 22, 2018 @07:15AM (#16647584)

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.

[ Parent | on HN ]

Re:Avoid getters and setters whenever possible by rhapsodic on Thursday March 22, 2018 @07:45AM (#16647733)

> It degrades the concept of objects being smart independent entities.

"Smart independent entities"? That's a new one on me. What does that mean?

[ Parent | on HN ]

Re:Avoid getters and setters whenever possible by frou_dh on Thursday March 22, 2018 @08:13AM (#16647896)

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.

[ Parent | on HN ]

Re:Avoid getters and setters whenever possible by spdionis on Thursday March 22, 2018 @07:44AM (#16647718)

Getters/setters vs public properties has nothing to do with encapsulation. Obviously not all properties are public/have getters and setters.

[ Parent | on HN ]

Re:Avoid getters and setters whenever possible by frou_dh on Thursday March 22, 2018 @07:54AM (#16647776)

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.

[ Parent | on HN ]