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

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

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

他们绝对是邪恶的。

@coobird不幸的是，他们绝对没有“强制封装的概念”，他们所做的只是让你认为你在封装数据，而实际上你是通过一个方法宏伟的属性来暴露数据。getter/setter在公共字段中做的任何事情都做得更好。

首先，如果你想要公共数据，让它成为公共的，摆脱getter和setter方法，以减少客户端必须涉水处理的方法的数量，并使客户端通过eg改变它的值在认知上更简单。

object.field = value;

而不是更强烈的认知

object.setField(value);

客户端现在必须检查getter/setter方法，看看它是否有任何副作用。

其次，如果你真的需要在方法中做一些其他的事情，当它有比简单的获取或设置更多的职责时，为什么要把它称为get/set方法呢? 要么遵循SRP，要么就像Zarkonnen提到的例子一样，给这个方法起个名字，告诉你整个方法是怎么做的。

public void kill(){
    isAlive = false;
    removeFromWorld(this);
}

而不是

public void setAlive(boolean isAlive){
    this.isAlive = isAlive;
    if (isAlive)
        addToWorld(this);
    else
        removeFromWorld(this);
}

在哪里setAlive(布尔)方法告诉客户端，作为一个副作用，它将从世界上删除对象?客户端为什么要了解isAlive字段?再加上当对象被重新添加到世界中时会发生什么，它应该被重新初始化吗?客户为什么会关心这些?

恕我直言，这里的寓意是要给方法命名，准确地说出它们做了什么，遵循SRP，去掉getter /setter。 如果在没有getter /setter的情况下出现问题，告诉对象在它们自己的类中做它们自己的脏工作，而不是试图在其他类中与它们一起做事情。

我的咆哮到此结束，对不起;)

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

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

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

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

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

getter和setter的出现往往表明(如果你喜欢那种小学语言，这是一种“气味”)存在设计问题。琐碎的getter和setter与公共字段几乎没有区别。通常情况下，对数据进行操作的代码将位于不同的类中——封装性很差，这是不熟悉OO的程序员所期望的。

在某些情况下，getter和setter都很好。但作为规则，同时具有getter和setter的类型表明存在设计问题。getter为不变性工作;setter的作用是“告诉而不是问”。不变性和“告诉不要问”都是很好的设计选择，只要它们没有以重叠的风格应用。