thufir said:
Is there a technical reason Java can't use the Ruby approach to getter
and setter methods?
-Thufir
I myself think the Java approach is OK.
For starters, let's agree that the "effort" argument is nonsensical. A
modern IDE saves you all the typing.
The code bloat/readability argument has some small merit...not so much the
bloat, but the readability. Me, I just use the IDE to park the accessors out
of the way in a clearly labelled section of the class. In any case, with
IDEs you can easily jump to where you need to go.
The real issue is class design. Can you justify your getters and setters,
each and every one? Who needs to use them...the class itself, subclasses,
classes in the package, or everyone? How many setters (apart from say
private ones) do you need after you've carefully considered what
constructors make sense? Carefully choosing the class methods to maximize
the amount of work done *inside* the class cuts down on getters and setters
too.
We also cut down on accessors with a careful analysis of what the *logical*
class attributes really are. At a given moment a certain class may have 5
logical attributes, but 12 instance variables that implement those logical
attributes. Along with a number of constructors (hopefully knowing quite
little about those instance variables) and perhaps one or two value objects
for information passing (if truly required), there may be only 2 setters and
certainly no more than 5 getters. For example, a personName may only need
one getter (returning a String) but may have half a dozen private instance
fields to store its bits. Point being, the Ruby/C# approaches show off best
with a certain category of objects, quite simplistic ones.
AHS