目前,我正在开发一款带有多种不同模式的Java简单游戏。我已经扩展了一个主Game类,将主要逻辑放在其他类中。尽管如此,游戏的主要职业仍然相当庞大。
在快速浏览了我的代码后,我发现比起游戏逻辑真正需要的其他内容,大部分内容都是getter和setter(60%)。
一些谷歌搜索声称getter和setter是邪恶的,而另一些人则声称它们是良好的OO实践和伟大的程序所必需的。
那我该怎么办呢?应该是哪一个呢?我是否应该为我的私有变量改变我的getter和setter,还是应该继续使用它们?
目前,我正在开发一款带有多种不同模式的Java简单游戏。我已经扩展了一个主Game类,将主要逻辑放在其他类中。尽管如此,游戏的主要职业仍然相当庞大。
在快速浏览了我的代码后,我发现比起游戏逻辑真正需要的其他内容,大部分内容都是getter和setter(60%)。
一些谷歌搜索声称getter和setter是邪恶的,而另一些人则声称它们是良好的OO实践和伟大的程序所必需的。
那我该怎么办呢?应该是哪一个呢?我是否应该为我的私有变量改变我的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那么重要。
其他回答
一如既往,唯一的答案是:视情况而定。如果你是唯一接触代码的人,你可以做任何你觉得舒服的事情,包括走捷径。
使用setter的好处之一是只需要在代码中的一个位置执行检查。
您可能需要更仔细地关注这些方法实际获取和设置的内容。如果您使用它们来提供对常量值的访问,那么使用常量可能更好。
还有一种观点认为,在大多数情况下,使用setter仍然会破坏封装,因为它允许您设置毫无意义的值。举个非常明显的例子,如果你在游戏中设置了一个只会上升的分数计数器,而不是
// Game
private int score;
public void setScore(int score) { this.score = score; }
public int getScore() { return score; }
// Usage
game.setScore(game.getScore() + ENEMY_DESTROYED_SCORE);
应该是这样
// Game
private int score;
public int getScore() { return score; }
public void addScore(int delta) { score += delta; }
// Usage
game.addScore(ENEMY_DESTROYED_SCORE);
这可能是一个简单的例子。我想说的是,讨论getter/setter与公共字段通常会掩盖更大的问题,即对象以亲密的方式操纵彼此的内部状态,因此耦合过于紧密。
这个想法是让方法直接做你想做的事情。一个例子便是如何设置敌人的“活着”状态。您可能会想使用setAlive(boolean alive)方法。相反,你应该:
private boolean alive = true;
public boolean isAlive() { return alive; }
public void kill() { alive = false; }
这样做的原因是,如果你改变实现,事情不再有一个“活着”布尔值,而是一个“命中值”值,你可以在不破坏你之前写的两个方法的契约的情况下改变它:
private int hp; // Set in constructor.
public boolean isAlive() { return hp > 0; } // Same method signature.
public void kill() { hp = 0; } // Same method signature.
public void damage(int damage) { hp -= damage; }
getter和setter的出现往往表明(如果你喜欢那种小学语言,这是一种“气味”)存在设计问题。琐碎的getter和setter与公共字段几乎没有区别。通常情况下,对数据进行操作的代码将位于不同的类中——封装性很差,这是不熟悉OO的程序员所期望的。
在某些情况下,getter和setter都很好。但作为规则,同时具有getter和setter的类型表明存在设计问题。getter为不变性工作;setter的作用是“告诉而不是问”。不变性和“告诉不要问”都是很好的设计选择,只要它们没有以重叠的风格应用。
我并不真的认为他们是邪恶的。但我很想生活在一个除非真的需要,我才会用到它们的世界里。
上面我读到的一个例子是对代码进行未来验证。例如:
public void setValue(int value)
{
this.value = value;
}
然后,需求发生变化,您需要跟踪该值设置了多少次。
So:
public void setValue(int value)
{
this.value = value;
count++;
}
真漂亮。我明白了。但是,在Ruby中,下面的代码不能达到同样的目的吗?
someobject.my_value = 100
稍后,您需要跟踪my_value被设置的次数。那么,你能不重写setter then和only then吗?
def my_value=(value)
@my_value = value
@count++
end
我很喜欢漂亮的代码,但我不得不承认,在我们拥有的Java类的大山中,看到成千上万行只是基本的getter/setter的代码是丑陋和讨厌的。
当我全职用c#开发时,我们一直使用公共属性,只在需要时才使用自定义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那么重要。