6 ms·
Getters are setters are pointless anyway - unless you're creating read-only properties by only providing getters, reflexively adding a getter and a setter for e
by commandlinefan 6y ago
Getters are setters are pointless anyway - unless you're creating read-only properties by only providing getters, reflexively adding a getter and a setter for every property is exactly the same as just marking the property public. It's even worse in the case of immutable objects (like lists or maps), because the getter itself returns a reference to the mutable object. Getters and setters mentality came from a horrible misunderstanding of object oriented design principles and has been standardized into common practice.
- slver 6y agoget()/set() is the same as a public property, until you change the implementation, while maintaining interface compatibility, which is the point. In C# you'd have a point, they have parametric properties and readonly properties. So you'd favor just declaring public properties. But this is why context matters. And OO design principles also depend on this context.
- marcosdumay 6y ago> until you change the implementation, while maintaining interface compatibility, which is the point How many times have you seen that done on the real world? And how many times have you seen that done, and it not creating a lot of bugs because of the behavior change without interface changes? Personally, I've seen the first one more than zero times. Not the second. Every single time somebody decided to mess with a setter or a getter, it broke the systems that depended on it, and things would have been much better if they simply changed the interface, so the problems would arrive at compile time.
- slver 6y agoThe behavior doesn’t change. The implementation does. Those are orthogonal. And yes I see it every day. The collection interfaces in Java have countless swappable implementations. Those are basically getters and setters on a vector. I also had to change entity storage to columnar for a project. Did that. Never had to change a line of code outside the entities.
- whatshisface 6y agoIn languages without property support, reflexively writing getters and setters is the only way to make it possible to go back later and add logic to getting and setting without changing the callsites. Is this a workaround for the combined shackles of mismanaged enterprise environments where changing callsites is impossible for some reason, and legacy language environments where you have to use Java for some reason? Yes, of course. But sometimes you need a workaround.
- slver 6y agoThe real question is why is the convention getFoo() setFoo(foo) and not foo() and foo(foo).
- whatshisface 6y agoNot all languages have overloading.
- slver 6y agoI'm referring to Java.
- whatshisface 6y agoI think the pattern was adopted from languages before Java which didn't have overloading.
- swsieber 6y agoIt makes for easier searching in small code bases with stuff like grep instead of needing full language server / ide support.
- commandlinefan 6y ago> go back later and add logic to getting and setting Which, realistically, you're virtually never going to do - at least not often enough to justify the boilerplate and especially in the case of things like "records" which were probably auto-generated from a schema (with obligatory getters and setters) anyway. If you did, you'd end up confusing all of your callers who probably wrote client code presuming that what they provided in the setter was going to be exactly what they get back in the getter.