目前,我正在开发一款带有多种不同模式的Java简单游戏。我已经扩展了一个主Game类,将主要逻辑放在其他类中。尽管如此,游戏的主要职业仍然相当庞大。
在快速浏览了我的代码后,我发现比起游戏逻辑真正需要的其他内容,大部分内容都是getter和setter(60%)。
一些谷歌搜索声称getter和setter是邪恶的,而另一些人则声称它们是良好的OO实践和伟大的程序所必需的。
那我该怎么办呢?应该是哪一个呢?我是否应该为我的私有变量改变我的getter和setter,还是应该继续使用它们?
目前,我正在开发一款带有多种不同模式的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的所有原因中,性能并不是其中之一(有些人可能会认为)。JVM足够智能,可以内联琐碎的getter /setter(甚至是非最终的getter /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; }
我并不真的认为他们是邪恶的。但我很想生活在一个除非真的需要,我才会用到它们的世界里。
上面我读到的一个例子是对代码进行未来验证。例如:
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是非常非常邪恶的。它们本质上让您假装隐藏对象的内部,而大多数情况下您所做的一切都是在多余的代码中进行的,这些代码无法隐藏内部状态。对于一个简单的POJO,没有理由不能用obj.name = "Tom"替换getName()和setName()。
如果方法调用只是替换赋值,那么选择方法调用所得到的只是代码膨胀。不幸的是,该语言在JavaBeans规范中规定了getter和setter的使用,因此Java程序员被迫使用它们,即使这样做毫无意义。
幸运的是,Eclipse(可能还有其他ide)允许您自动生成它们。在一个有趣的项目中,我曾经用XSLT为它们构建了一个代码生成器。但如果有一件事是我想在Java中摆脱的,那就是对getter和setter的过度依赖。
如果需要外部访问字段的各个值,请使用getter和/或setter。如果不是,那就不要。永远不要使用公共字段。就这么简单!(好吧,从来没有那么简单,但这是一个很好的经验法则)。
通常情况下,您还会发现您需要提供setter的次数比getter少得多——特别是当您试图使对象不可变时——这是一件好事(但并不总是最好的选择)——但即使不是这样。