Java 方法命名约定 : Too many getters

Question

为什么 Java 方法名称如此广泛地使用“get”前缀？至少在我的 Java 程序中，有很多名称以“get”开头的方法。获取方法的百分比非常高。我开始觉得“得到”这个词由于通货膨胀而失去了意义。这是我的代码中的噪音。

我注意到在函数式/声明式编程和 PL/SQL 中使用了不同的命名约定。方法名称只是说明方法返回的内容。他们将使用 account.amount() 和 Time 而不是 account.getAmount() 或 Time.getIsoFormattedDateString(Date date)。 isoFormattedDateString(日期日期)。这对我来说非常有意义，因为函数的名称描述了评估方法的结果(假设没有副作用，无论如何都不应该有)。 “get”前缀似乎是多余的。

我刚刚开始阅读“清洁代码”一书。它说方法应该只做一件事，而那件事通常应该是以下之一:

1. 通知某个对象有关事件，通常将事件作为参数传递。
2. 询问有关某个对象的问题，通常使用形成自然语言语句的方法名称，将对象作为参数传递并返回 boolean 值。
3. 获取一些东西，可能传递一些查找键或一些要转换的对象作为参数，并始终返回所需的对象/值。

我的问题是关于第三类的。这种方法除了“get”之外还有命名约定吗？您在选择方法名称/前缀时使用什么标准？

这是一个例子:

我有一个类有两个方法 getDates() 和 getSpecialDates()。 getDates() 只返回一个私有(private)变量的值(对日期集合的引用)。据我了解，这是一个标准的 setter/getter 。 getSpecialDates() 不同；它调用 getDates()，从另一个类中获取过滤器，应用过滤器并返回实际上是 getDates() 的子集。

getSpecialDates() 方法可以命名为 computeSpecialDates()、findSpecialDates()、selectSpecialDates() 或 elicitSpecialDates() 之类的。或者我可以简单地将其命名为 specialDates()。然后，为了保持一致性，我可以将 getDates() 重命名为 dates()。

为什么要区分应该以“get”为前缀的方法和不应该以“get”为前缀的方法，为什么还要为“get”寻找替换词？

Answer 1

我个人尽可能不使用 getter 和 setter(意思是:我不使用任何需要它的框架，例如 Struts)。

我更喜欢尽可能编写 不可变 对象(public final 字段)，否则我只使用公共(public)字段:更少的样板代码，更高的生产力，更少的副作用。 get/set 最初的理由是封装(让你的对象尽可能害羞)，但事实上，我并不经常需要它。

在Effective Java中，Joshua Bloch 提出了这个令人信服的建议:

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.

在同一本书中，他还说(但我不想在这里复制整本书):

The JavaBeans pattern has serious disadvantages.

我完全同意这一点，因为 JavaBeans 最初是为一个非常狭窄的问题领域设计的:在 IDE 中操作图形组件。使用为解决另一个问题而设计的解决方案是一种不好的做法。