4 ms·

Second comment I have seen mentioning JavaBeans style getters and setters. What is the issue with it?

• ywei3410 6y ago
  There's nothing specifically wrong with it; just that dogma without understanding why you're doing it is always problematic. If your coding rules state that /every/ object with any properties needs an associated getter/setter/Builder/Factory for any code then it quickly leads to a huge amount of code and indirection to do the most trivial of tasks - made worse by the fact that Java doesn't have first-class macros. In regards to getters and setters specifically; this stackoverflow post is quite good [1]. If those reasons don't apply then it just ends up complicating the solutions for very little benefit. [1] https://stackoverflow.com/questions/1568091/why-use-getters-and-setters-accessors https://stackoverflow.com/questions/1568091/why-use-getters-...
  • ivan_gammel 6y ago
    Actually there is something specific: while individual field accessors may make sense in some use cases (ActiveRecord or bidirectional UI mapping), the naming convention for them chosen in JavaBeans (“get/setXxx”) is too verbose and doesn’t make sense at all. Compare: 1. a.getFoo().getBar() vs a.foo().bar() or a.foo.bar 2. a.setFoo(1); a.setBoo(“moo”); vs a.foo(1).boo(“moo”); or a.onSomeEvent(1, “moo”); JavaBeans are often used in reflective mapping, but nothing prevents from using simpler convention the same way.
    • ywei3410 6y ago
      That's a fair point. I hadn't considered the names at all; I suppose one could argue that a three letter prefix is the least of Java's verbosity woes.
    • forgotmypw17 6y ago
      In my opinion, the three extra characters are worth it for reducing ambiguity. For example, it's clear to me what setFoo() and getFoo() does, but what about foo()? Does that return the value of foo() or does it run a process called foo()? JavaScript has a different but also unambiguous way of doing it, with a.foo used for properties, and a.foo() used for function. foo() is neither here nor there.
      • ivan_gammel 6y ago
        The contexts in which this question would make sense are very rare, so no, it does not worth it. Let me also quote Brian Goetz on this topic: „No discussion involving boilerplate (or any question of Java language evolution, for that matter) can be complete without the subject of field accessors (and properties) coming up. On the one hand, accessors constitute a significant portion of the boilerplate in existing code; on the other hand, the JavaBean-style getter/setter conventions are already badly overused. Mutability may drag with it encapsulation, and encapsulation plus transparency may in turn drag accessors with them, but we should be mindful of the purpose of these accessors; it is not to abstract the representation from the API, but at most to enable rejection of bad values and provide syntactic uniformity of access. (Without rehashing the properties debate, one fundamental objection to automating JavaBean-style field accessors is that it would take what is at best a questionable -- and certainly overused -- API naming convention and burn it into the language. Unlike the core methods like Object.equals(), field accessors do not have any special treatment in the language, and so names of the form getSize() should not either. Also, while equally tedious, writing (and reading) accessor declarations are not nearly as error-prone as equals().)“