4 ms·
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.
by 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 agoThats 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 agoAgreed 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 agoInstead 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 agoLombok (https://projectlombok.org https://projectlombok.org) exists and takes care of the attribute issue you mentioned.
- ecshafer 9y agoYou can use setters that return a reference to a new object with the updated says, using some copy and delete mechanism for immutability.