[josm-dev] Jumbo Patch

[Gervase Markham]

Ulf Lamping wrote:
> Well, that argument is wrong IMHO. If there are a few hundred lines of 
> getters and setters in each file and I fully want to understand the code 
> I have to read all of it. I don't know what there might be, as there 
> could be some additional code in the get/set methods.

If that's true, then it was clearly a good idea to have them, because 
people have been able to add that code without having to change all the 
callers :-)

Skimming over them using page-down, it's clear which ones are just 
"getFoo { return foo; }" and which are more complicated.

> All in all, this getter/setter thing sounds like another "karma" of 
> programming (like tab vs. space, the right indenting, ...) - there's no 
> "one and only truth". So arguing is pretty pointless, as both sides will 
> have their believe and won't convince each other ...

If that were true, then it would be impossible to develop _any_ best 
practice in software development at all, because everything is disputed 
by someone. But I don't think either of you actually believes that.

Best practices in Java programming do exist. The guys at Sun, who 
invented the language, have code conventions which most Java programmers 
follow because they respect their expertise and because they have been 
found to be good ideas in practice. Here's what they say about public 
access to variables:

"10.1 Providing Access to Instance and Class Variables

Don't make any instance or class variable public without good reason. 
Often, instance variables don't need to be explicitly set or 
gotten-often that happens as a side effect of method calls.

One example of appropriate public instance variables is the case where 
the class is essentially a data structure, with no behavior. In other 
words, if you would have used a struct instead of a class (if Java 
supported struct), then it's appropriate to make the class's instance 
variables public."
http://java.sun.com/docs/codeconv/html/CodeConventions.doc9.html#177

In other words, generally don't allow public access to variables unless 
your class is very simple. But also (and I agree, this speaks against 
long lists of getters and setters), your classes should have methods 
which do more than just get and set values - i.e. they should have 
behaviour as well. And calling the behavioural methods should manipulate 
the member variables along the way.

So perhaps the right way forward is to use getters and setters, but as 
development continues to try and refactor classes to encapsulate 
behaviour better, thereby reducing the amount of raw getter/setter code.

(One other thought: using getters and setters also makes automated 
refactoring a while lot easier, which is a non-trivial gain.)

Gerv