Java method naming conventions: Too many getters

Question

Why do Java method names use the "get" prefix so extensively? At least in my Java programs there are a lot of methods with names starting with the word "get". The percentage of get-methods is suspiciously high. I am starting to feel that the word "get" is losing its meaning because of inflation. It is noise in my code.

I have noticed that there is a different naming convention being used in functional/declarative programming and PL/SQL. The method name simply states what the method returns. Instead of account.getAmount() or Time.getIsoFormattedDateString(Date date) they will use account.amount() and Time.isoFormattedDateString(Date date). This makes perfect sense to me, as the name of the function describes the result of evaluating the method (assuming there are no side effects, which there shouldn't be anyway). The "get" prefix seems superfluous.

I have just started reading the book "Clean Code". It says that methods should do only one thing, and that that thing should normally be one of the following:

1. Notify some object about an event, typically passing the event as a parameter.
2. Ask a question about some object, typically with the method name forming a natural language statement, passing the object as parameter and returning a boolean.
3. Fetch something, possibly passing some lookup key or some object to be converted as parameter and always returning the desired object/value.

My question is about the third category. Are there naming conventions other than "get" for this kind of methods? What criteria do you use when choosing method names/prefixes?

Here is an example:

I have a class with two methods getDates() and getSpecialDates(). getDates() simply returns the value of a private variable (the reference to a collection of dates). This is a standard getter, as I understand it. getSpecialDates() is different; it calls getDates(), fetches a filter from another class, applies the filter and returns what is effectively a subset of getDates().

The method getSpecialDates() could be named computeSpecialDates(), findSpecialDates(), selectSpecialDates() or elicitSpecialDates() or whatever. Or I could simply name it specialDates(). And then, for consistency, I could rename getDates() into dates().

Why bother separating between methods that should be prefixed with "get" and methods that should not, and why bother finding replacement words for "get"?

Answer 1

I personally don't use getters and setters whenever it's possible (meaning : I don't use any framework who needs it, like Struts for instance).

I prefer writing immutable objects (public final fields) when possible, otherwise I just use public fields : less boiler plate code, more productivity, less side effects. The original justification for get/set is encapsulation (make your objects as shy as possible), but in fact, I don't need it very often.

In Effective Java, Joshua Bloch makes this compelling recommendation :

Classes should be immutable unless there's a very good reason to make them mutable... If a class cannot be made immutable, limit its mutability as much as possible.

In the same book, he also says (but I don't want to copy the whole book here) :

The JavaBeans pattern has serious disadvantages.

I totally aggre with that, since JavaBeans were originally intended for a very narrow problem domain : manipulation of graphical components in an IDE. It is a bad practice to use one solution designed for solving another problem.