仅供参考:除了这篇文章中所有优秀的答案之外，请记住，在您可以提出的支持或反对getter /setter的所有原因中，性能并不是其中之一(有些人可能会认为)。JVM足够智能，可以内联琐碎的getter /setter(甚至是非最终的getter /setter，只要它们没有被实际覆盖)。

如果Game类暴露了那么多变量，那么它可能遵循god对象反模式。getter和setter并没有什么问题(尽管它们在Java中的冗长可能会有点烦人);在一个设计良好的应用程序中，每个类都有明确分离的功能，你不需要在一个类中包含数十个类。

编辑:如果getter和setter的主要目的是“配置”游戏类(我是这样理解你的评论的)，那么你可能不需要getter(一个类不使用get方法就可以访问自己的私有变量)，你可能可以将许多setter折叠成“组setter”，设置几个概念上属于一起的变量。

这是滑坡效应。

简单的Transfer对象(或Parameter对象)的唯一目的可能是保存某些字段，并根据需要提供它们的值。然而，即使在这种退化的情况下，也可以认为对象应该是不可变的——在构造函数中配置，并且只公开get…方法。

还有一个类暴露了一些“控制旋钮”;你的汽车收音机的UI可能被理解为公开类似getVolume、setVolume、getChannel和setChannel的东西，但它的真正功能是接收信号和发出声音。但是这些旋钮并没有暴露太多的实现细节;从这些接口特征上，你无法知道收音机是晶体管(主要是软件)还是真空管。

越是开始将对象视为问题域任务的积极参与者，就越会认为是要求它做一些事情，而不是要求它告诉您它的内部状态，或者要求它提供它的数据，以便其他代码可以使用这些值做一些事情。

所以…“邪恶”?不是真的。但每次你倾向于输入一个值并暴露它们都会得到。并设置…方法，问问自己为什么，以及该对象的真正职责是什么。如果你能给自己的唯一答案是，“为我保留这个值”，那么可能有OO之外的东西在这里。

我的观点是getter和setter是好的程序的必要条件。坚持使用它们，但不要编写不必要的getter /setter -并不总是需要直接处理所有变量。

非常邪恶:公共领域。 有点邪恶:在不需要的地方使用getter和setter。 好:getter和setter只在真正需要的地方使用——使类型暴露“更大”的行为，恰好使用它的状态，而不是仅仅将类型视为供其他类型操作的状态存储库。

不过，这真的取决于情况-有时您真的只是想要一个愚蠢的数据对象。

一如既往，唯一的答案是:视情况而定。如果你是唯一接触代码的人，你可以做任何你觉得舒服的事情，包括走捷径。

使用setter的好处之一是只需要在代码中的一个位置执行检查。

您可能需要更仔细地关注这些方法实际获取和设置的内容。如果您使用它们来提供对常量值的访问，那么使用常量可能更好。