4 ms·

The author is suggesting that some getters and setters--particularly the ones that introduce a public method to replace a property against a private variable wi

The author is suggesting that some getters and setters--particularly the ones that introduce a public method to replace a property against a private variable without introducing any actual value-added logic or protection--are counter-productive. I've been pondering the following things recently in relation to the glue code in Java issue: 1) IDEs often require Beans be created, which require getters and setters. So, if you have to use IDEs, you are pushed towards getters and setters in many cases to create Bean-compatible classes. 2) Rather than stuffing all this in the code and creating explicit glue, would it be possible to implement an interface which adds getters and setters for Bean compatibility at runtime if explicit ones have not been created (ostensibly because there is no value to add in the method body that provides additional logic or security)? I need to get back in to this and see if its possible or even makes sense. I've been out of Java since 2000.

LogicHoleFlaw 18y ago
In Java, exposing public instance variables of a class is risky because any changes to the internal operation of that class requires modification to the callers of that class. If you write your accessor methods up front then you can add additional behavior to those accesses at a later point in time. That is largely a syntactical issue. A similar reasoning causes the proliferation of interfaces and factories. The inability to dynamically create objects at run-time leads to a great deal of indirection created at write-time and compile time. That's a semantic issue which creates tons of complexity for little gain. Beans are a direct response to these limitations. For instance with most dependency injection frameworks you can alter an XML file to rewire Bean creation without having to recompile or modify the source of your Java codebase. It's a hack emulating a subset of the capabilities of dynamic metaprogramming. The Bean style of operation greatly encourages all of these verbose design styles. Some of it can be avoided through introspection, aspects, and annotations, but that is very clumsy in Java. Java practices have indeed changed a lot since 2000 but the increase in incidental complexity is just stunning. (major edits: expound upon my points.)

LogicHoleFlaw 18y ago

In Java, exposing public instance variables of a class is risky because any changes to the internal operation of that class requires modification to the callers of that class. If you write your accessor methods up front then you can add additional behavior to those accesses at a later point in time. That is largely a syntactical issue. A similar reasoning causes the proliferation of interfaces and factories. The inability to dynamically create objects at run-time leads to a great deal of indirection created at write-time and compile time. That's a semantic issue which creates tons of complexity for little gain. Beans are a direct response to these limitations. For instance with most dependency injection frameworks you can alter an XML file to rewire Bean creation without having to recompile or modify the source of your Java codebase. It's a hack emulating a subset of the capabilities of dynamic metaprogramming. The Bean style of operation greatly encourages all of these verbose design styles. Some of it can be avoided through introspection, aspects, and annotations, but that is very clumsy in Java. Java practices have indeed changed a lot since 2000 but the increase in incidental complexity is just stunning. (major edits: expound upon my points.)