目前,我正在开发一款带有多种不同模式的Java简单游戏。我已经扩展了一个主Game类,将主要逻辑放在其他类中。尽管如此,游戏的主要职业仍然相当庞大。

在快速浏览了我的代码后,我发现比起游戏逻辑真正需要的其他内容,大部分内容都是getter和setter(60%)。

一些谷歌搜索声称getter和setter是邪恶的,而另一些人则声称它们是良好的OO实践和伟大的程序所必需的。

那我该怎么办呢?应该是哪一个呢?我是否应该为我的私有变量改变我的getter和setter,还是应该继续使用它们?


当前回答

关于这个问题,你们已经有了很多很好的答案,所以我只是发表我的意见。getter和setter是非常非常邪恶的。它们本质上让您假装隐藏对象的内部,而大多数情况下您所做的一切都是在多余的代码中进行的,这些代码无法隐藏内部状态。对于一个简单的POJO,没有理由不能用obj.name = "Tom"替换getName()和setName()。

如果方法调用只是替换赋值,那么选择方法调用所得到的只是代码膨胀。不幸的是,该语言在JavaBeans规范中规定了getter和setter的使用,因此Java程序员被迫使用它们,即使这样做毫无意义。

幸运的是,Eclipse(可能还有其他ide)允许您自动生成它们。在一个有趣的项目中,我曾经用XSLT为它们构建了一个代码生成器。但如果有一件事是我想在Java中摆脱的,那就是对getter和setter的过度依赖。

其他回答

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

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

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

getter和setter强化了面向对象编程中的封装概念。

通过对外部世界隐藏对象的状态,对象可以真正地控制自己,并且不能以非预期的方式进行更改。操纵对象的唯一方法是通过公开的公共方法,例如getter和setter。

使用getter和setter有一些好处:

1. 允许将来在不修改使用已修改类的代码的情况下进行更改。

使用getter和setter的最大优势之一是,一旦定义了公共方法,当底层实现需要更改时(例如,找到一个需要修复的bug,使用不同的算法来提高性能等),通过将getter和setter作为操作对象的唯一方法,它将允许现有代码不会中断,即使在更改之后也能按预期工作。

例如,我们说有一个setValue方法,它在一个对象中设置值私有变量:

public void setValue(int value)
{
    this.value = value;
}

但是,有一个新的要求,需要跟踪值被更改的次数。设置好setter后,更改相当简单:

public void setValue(int value)
{
    this.value = value;
    count++;
}

如果值字段是公共的,那么稍后就无法返回并添加一个计数器来跟踪值被更改的次数。因此,使用getter和setter是一种“不受未来影响”的方法,以应对以后可能发生的更改。

2. 强制执行操纵对象的手段。

getter和setter的另一种方便方式是强制操作对象的方式,因此,对象可以控制自己的状态。公开对象的公共变量很容易被破坏。

例如,一个ImmutableArray对象包含一个名为myArray的int数组。如果数组是一个公共字段,它就不是不可变的:

ImmutableArray a = new ImmutableArray();
int[] b = a.myArray;
b[0] = 10;      // Oops, the ImmutableArray a's contents have been changed.

要实现一个真正不可变的数组,应该编写一个数组的getter (getArray方法),以便它返回其数组的副本:

public int[] getArray()
{
    return myArray.clone();
}

即使发生以下情况:

ImmutableArray a = new ImmutableArray();
int[] b = a.getArray();
b[0] = 10;      // No problem, only the copy of the array is affected.

ImmutableArray确实是不可变的。公开对象的变量将允许以不预期的方式操作对象,但只有公开某些方式(getter和setter),对象才能以预期的方式操作。

我认为getter和setter对于作为API的一部分并将被其他人使用的类更重要,因为它允许在允许更改底层实现的同时保持API的完整和不变。

有了getter和setter的所有优点,如果getter只是返回私有变量的值,而setter只是接受一个值并将其分配给私有变量,那么getter和setter似乎只是多余的,实际上是一种浪费。如果类将仅供应用程序内部使用,而不供其他应用程序使用,那么广泛使用getter和setter可能不像编写公共API那么重要。

他们绝对是邪恶的。

@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的情况下出现问题,告诉对象在它们自己的类中做它们自己的脏工作,而不是试图在其他类中与它们一起做事情。

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

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

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