6 ms·

The weird thing is you dont even need getters and setters, you can make member variables public (and final if you have to). Just its the Java culture that is so

• xxs 6y ago
  getters/setters became popular with RMI. Public fields have all kind of security/code smell issues. Most classes should be immutable.
  • JulianMorrison 6y ago
    Public writeable fields are threading and encapsulation smells but public read-only fields just say, this data is part of my interface.
    • deleted 6y ago
      [deleted]
    • xxs 6y ago
      well, yes however fields cannot be part of an 'interface' in java. (they can but they'd be static) I do use package private fields liberally, though. Just not non-static public fields.
      • JulianMorrison 6y ago
        Interface as used here means the broader concept of a "a class's interface is its public advertised operations" and not the specific Java thing called an interface.
• derefr 6y ago
  I don’t fault Java programmers for their “love” of getters/setters; they’re taking something that really is a best-practice in certain situations, and which mostly doesn’t hurt otherwise (that best-practice being “making the contractual interface for an object its methods, so that the implementation can change while the interface remains stable”) and just deciding to do it all the time rather than only when it will likely have future benefits. Which makes a lot of sense, if you look at it through the lens of cultural anthropology. Enterprises dictate approaches like this, because the alternative is leaving the choice to the individual programmer — and these same enterprises don’t hire experienced-enough programmers to trust their judgement. And so all the programmers who work for these enterprises end up absorbing this approach as a social norm, just “something you do”, rather than “independently rediscovering the need for it” in a way that would lead to them actually knowing when it’s useful. So, even when not locked into an enterprise that forces it on them, they just keep doing it, because that’s the culture that’s been inculcated on them (and how all the examples look, how all the libraries do it, etc.) Personally, I’m not in theory against “unilateral” use of getters/setters, either. I just kind of which they worked in Java the way they work in Ruby: where referencing a field on any object other than `this` would actually just be sugar for a call to the getter/setter. Where the Java optimizer would then take special care to optimize-away the call frame for known-‘trivial’ getters/setters.
  • The_rationalist 6y ago
    This is why Kotlin has the best of both worlds. You can access a variable through A.b and it will automatically call the getter if there's one
    • mgkimsal 6y ago
      groovy did/does this too. any property automatically has a getter/setter in the compiled code if an explicit getter or setter doesn't exist.
    • kabes 6y ago
      Javascript can do the same, but I think it's an anti pattern, since now the caller doesn't know what side effects, or performance characteristics you get by accessing the property with an implicit getter/setter.
      • dragonwriter 6y ago
        > now the caller doesn't know what side effects, or performance characteristics you get by accessing the property with an implicit getter/setter. Beyond method call overhead (which may or may not be a given depending on how things are optimized in some languages), the caller doesn't know that automatically with explicit getters/setters, either; you'd have to read the source to know that just as much if they are explicit as implicit (or rely on documentation, which hopefully is complete and current).
    • augustk 6y ago
      In the programming language Eiffel this is called the uniform access principle.
      • edflsafoiewq 6y ago
        The uniform access principle is that features are "available through a uniform notation, which does not betray whether they are implemented through storage or through computation"; it doesn't imply anything about what the uniform notation is. Java-style getters/setters also achieve the uniform access principle; everything is accessed only via get_X()/set_X() and never a raw field .X that would betray it was implemented through storage.
• c00lc4t95 6y ago
  Java developer 6yrs here. I've worked in code bases and extended internal libraries that forgo the getters/setters model, for exposing member variables directly, and it's not better. If you ever need to change something about that value, do additional logic before returning (I e. emit metrics), or model a data class with an interface having getter methods makes these so much easier.
• JulianMorrison 6y ago
  I have a tendency to do "public final" variables and set them in the constructor for data objects. There's this weird hangover from Smalltalk and the idea that everything should be overridable that wants getter and setters to be functions, when basically a read-only variable in an immutable data object is much simpler and just as safe. But for some dumbass reason it's not "the Java way".
  • pfarrell 6y ago
    Encouraging immutable data objects is “the Kotlin way”, though. You have explicitly mark properties as mutable (“var” instead of “val”). I didn’t get the value of this at first, but when we started catching bugs at coding tiime that would have been runtime errors in Java, I started to understand. This was among my takeaways from working with it in production for about two years.
    • JulianMorrison 6y ago
      In general Java it's still messy because although you can make the value of a variable immutable, the innards of the object it's holding are still mutable. Such as appending to a list. You have to go as far as Clojure does and create a whole new suite of truly immutable data containers, for full safety. I dunno if Kotlin goes this far. But yeah, it's the right way.
• acdha 6y ago
  I blame the culture, too. It’s unreal how many programmers have internalized this idea that simple code is somehow a personal failing. One factor I’ve thought about is how many Java programmers seem to have learned design by looking at things like the Java core libraries or a few open source frameworks, without recognizing that most people are not writing code intended to be generally reusable by millions of projects and that popularity means those projects cannot modernize their style easily, either. People write new code on new projects today as if it still needs to be compatible with the early 2000s because much of the code they learned from ossified around that time, and will claim it’s “best practice” because otherwise why would this Oracle/Apache API still use it?
• chapium 6y ago
  Getters are necessary because Java does not have read only attributes (except final).
• vbezhenar 6y ago
  You will need getters/setters for some fields. So your code will look weird: p.x = p.getY() + p.z; p.setY(p.x + p.z); It's better to use more universal approach, so your code will look unified. Another thing why getters/setters are preferable is because when you need to replace field with computed value, you would need to replace all your code. Proper approach would be to use properties which are available for every language but Java. They invented records, which somewhat fill that niche.
  • augustk 6y ago
    I don't like the idea of having a verb in the name of a pure function. I think it reads better to simply name the function after the result it returns.
  • deleted 6y ago
    [deleted]
  • eweise 6y ago
    I've used Java for over 20 years. Not once have I ever replaced an attribute with a computed value. Also p.x = p.y + p.z is much easier read. Another drawback of getters and setters is that you end up not looking at that code because you assume you know what it does, so you can miss when someone puts logic into a setter or getter
• pjmlp 6y ago
  It was brought by Smalltalk and C++ developers, but I guess 25 years later many don't get that part of history.
• hakfoo 6y ago
  I think it's a YAGNI problem, perhaps not consciously stated. The premise is if we never touch the public members, we can one day update the setters to add validation, or analytics, or include some automated formatting shim inside the getter... But nobody actually does it.
• dragonwriter 6y ago
  You can make member variables public, but that means that changes to how you handle access become compatibility-breaking. If you use getters and setters, you have more future options without breaking backward compatibility. When you are making libraries that lots of other projects might depend on, this is probably more important than when making apps, especially relatively small apps. “Getter/setter from the start” optimizes for induced maintenance cost on dependent code. Now, in some other languages, access via getters/setters is at least source-compatible with field access, which makes this less of (or not at all, for dynamic languages, or if it is object and not just source compatibility) an issue. But that's not the case with Java.
  • acdha 6y ago
    > When you are making _libraries_ that lots of other projects might depend on I think that's the key part here: most developers are writing code which will rarely or never be reused but they _learn_ by looking at shared code, and shared code which is on a different development cycle by a team nobody knows, and the field doesn't hasn't had a great history of discussing how different tradeoffs are appropriate for different projects.
• vips7L 6y ago
  Or just use Java records. public record SomeViewModel(String name, int age) { }
• bcrosby95 6y ago
  Problem is lots of tooling and libraries you might integrate with assume getters and setters and literally won't work without them.