还有一种观点认为，在大多数情况下，使用 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 非常非常邪恶。它们本质上是让您假装隐藏对象的内部结构，而大多数时候您所做的一切都被扔进了对隐藏内部状态没有任何作用的冗余代码中。对于一个简单的 POJO，没有理由不能将 getName() 和 setName() 替换为 obj.name = "Tom"。
如果方法调用仅仅代替了赋值，那么你通过更喜欢方法调用所获得的只是代码膨胀。不幸的是，该语言在 JavaBeans 规范中规定了 getter 和 setter 的使用，因此 Java 程序员被迫使用它们，即使这样做毫无意义。
幸运的是，Eclipse（可能还有其他 IDE）允许您自动生成它们。对于一个有趣的项目，我曾经在 XSLT 中为他们构建了一个代码生成器。但是，如果我想在 Java 中摆脱一件事，那就是过度依赖 getter 和 setter。
Getter 和 setter在面向对象编程中强制执行封装的概念。
通过将对象的状态隐藏在外部世界之外，对象真正掌控自己，并且不能以非预期的方式进行更改。可以操作对象的唯一方法是通过公开的公共方法，例如 getter 和 setter。
拥有 getter 和 setter 有几个优点：
1. 允许将来更改而不修改使用修改后的类的代码。
使用 getter 和 setter 的一大优势是，一旦定义了公共方法，就会有一段时间需要更改底层实现（例如，找到需要修复的错误，使用不同的算法来提高性能等），通过让 getter 和 setter 成为操作对象的唯一方法，它将允许现有代码不会中断，并且即使在更改之后也可以按预期工作。
例如，假设有一个setValue方法value在对象中设置私有变量：
public void setValue(int value)
{
this.value = value;
}
但是随后，有一个新的要求需要跟踪value更改的次数。使用 setter 后，更改就相当简单了：
public void setValue(int value)
{
this.value = value;
count++;
}
如果该value字段是公开的，则没有简单的方法可以稍后返回并添加一个跟踪值更改次数的计数器。因此，拥有 getter 和 setter 是一种让类“面向未来”以应对以后可能发生的变化的方法。
2. 执行可以操纵对象的方法。
getter 和 setter 派上用场的另一种方式是强制执行对象可以被操纵的方式，因此，对象可以控制自己的状态。暴露对象的公共变量后，它很容易被破坏。
例如，一个ImmutableArray对象包含一个int名为 的数组myArray。如果数组是一个公共字段，它就不会是不可变的：
ImmutableArray a = new ImmutableArray();
int[] b = a.myArray;
b[0] = 10; // Oops, the ImmutableArray a's contents have been changed.
要实现一个真正不可变的数组，应该为数组（getArray方法）编写一个 getter，以便它返回其数组的副本：
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 方法，以减少客户端必须涉足的方法数量，并使客户端在认知上更简单地更改它的值，例如。
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(boolean) 方法在哪里告诉客户端作为副作用它会从世界中删除对象？为什么客户端应该对 isAlive 字段有任何了解？另外，当对象重新添加到世界时会发生什么，是否应该重新初始化？为什么客户会关心这些？
恕我直言，道德是命名方法来准确说明他们所做的事情，遵循 SRP 并摆脱 getter/setter。如果没有 getter/setter 存在问题，请告诉对象在自己的类中做自己的脏活，而不是尝试在其他类中与它们一起做事。
我的咆哮到此结束，对此感到抱歉；）
这是一个滑坡。
一个简单的 Transfer 对象（或 Parameter 对象）的唯一目的可能是保存一些字段并按需提供它们的值。然而，即使在这种退化的情况下，人们也可以争辩说对象应该是不可变的——在构造函数中配置并且只公开get... 方法。
还有一个类暴露了一些“控制旋钮”的情况；您的车载收音机的 UI 可能可以理解为暴露了getVolume、setVolume、getChannel和之类的东西setChannel，但它的真正功能是接收信号和发出声音。但是这些旋钮并没有暴露太多的实现细节。你不知道收音机是晶体管，主要是软件还是真空管。
您越开始将对象视为问题域任务的积极参与者，您就越会考虑要求它做某事，而不是要求它告诉您它的内部状态，或者要求它它的数据，以便其他代码可以对这些值做一些事情。
所以……“邪恶”？并不真地。但是每次你倾向于输入一个值并在该值上公开get... 和set... 方法时，问问自己为什么，以及该对象的真正责任是什么。如果您能给自己的唯一答案是“为我保留这个价值”，那么可能除了 OO 之外还有其他事情正在发生。
如果你的 Game 类暴露了这么多变量，它可能会遵循上帝对象反模式。getter 和 setter 没有任何问题（尽管它们在 Java 中的冗长可能有点烦人）；在一个精心设计的应用程序中，每个类都有明确分离的功能，你不需要在一个类中使用几十个。
编辑：如果getter和setter的主要目的是“配置”游戏类（我理解你的评论），那么你可能不需要getter（一个类访问它自己的私有变量是完全可以的不使用 get 方法），并且您可能可以将许多设置器折叠成“组设置器”，这些设置器设置几个在概念上属于一起的变量。
getter 和 setter 的存在往往表明（如果您使用那种小学语言，那是一种“气味”）存在设计问题。微不足道的 getter 和 setter 与公共领域几乎没有区别。通常，对数据进行操作的代码将位于不同的类中 - 封装性差，以及您对不熟悉 OO 的程序员的期望。
在某些情况下，getter 和 setter 很好。但作为一项规则，同时具有 getter 和 setter 的类型表明存在设计问题。吸气剂为不变性工作；二传手为“告诉不问”工作。不变性和“告诉不要问”都是很好的设计选择，只要它们不以重叠的方式应用。
我的观点是，getter 和 setter 是好的程序的必要条件。坚持使用它们，但不要编写不必要的 getter/setter - 并不总是需要直接处理所有变量。
我真的不认为他们是邪恶的。但我很想生活在一个除非我真的需要，否则我永远不必使用它们的世界。
我在上面读到的一个例子是future-proofing你的代码。例如：
public void setValue(int value)
{
this.value = value;
}
然后，需求发生变化，您需要跟踪设置值的次数。
所以：
public void setValue(int value)
{
this.value = value;
count++;
}
这很漂亮。我得到它。但是，在 Ruby 中，以下内容不会起到同样的作用吗？
someobject.my_value = 100
稍后，您需要跟踪my_value被设置的次数。那么，你能不能只覆盖设置器THEN并且只覆盖THEN？
def my_value=(value)
@my_value = value
@count++
end
我完全喜欢漂亮的代码，但我必须承认，翻阅我们拥有的大量 Java 类，实际上看到了成千上万行代码，这些代码除了基本的 getter/setter 之外什么都不是，既丑陋又烦人。
当我全职使用 C# 进行开发时，我们一直使用公共属性，并且仅在需要时才使用自定义 getter/setter。像一个魅力一样工作，它没有破坏任何东西。
与往常一样，唯一的答案是：视情况而定。如果你是唯一接触代码的人，你可以做任何你喜欢的事情，包括走捷径。
使用 setter 的好处之一是只需要在代码中的一个位置执行检查。
您可能需要更密切地关注这些方法实际获取和设置的内容。如果您使用它们来提供对常量值的访问，那么使用常量可能会更好。
这取决于所讨论的编程语言。您的问题是在 Java 的上下文中提出的，似乎 getter 和 setter 通常被认为是一件好事。
相比之下，在 Python 世界中，它们通常被认为是糟糕的风格：它们在代码中添加了几行代码，但实际上并未添加功能。当 Python 程序员需要时，他们可以使用元编程来获取和/或设置对象属性。
在 Java 中（至少是我十年前稍微学过的 Java 版本），这是不可能的。因此，在 Java 中，通常最好虔诚地使用 getter 和 setter，这样如果需要，您可以覆盖对变量的访问。
（这并不意味着 Python 一定比 Java 更好，只是不同而已。）
仅供参考：除了此线程中的所有出色答案外，请记住，在您可以提出支持或反对 getter/setter 的所有原因中，性能不是一个（有些人可能认为）。JVM 足够聪明，可以内联琐碎的 getter/setter（即使是非 getter/setter final，只要它们实际上没有被覆盖）。
您可能想用值类替换一些类。这将允许您删除 getter 并避免在您更改内容时出现问题。
如果您需要对字段的各个值进行外部访问，请使用 getter 和/或 setter。如果没有，不要。永远不要使用公共领域。就这么简单！（好吧，它从来没有那么简单，但这是一个很好的经验法则）。
一般来说，您还应该发现您需要提供 setter 的频率比 getter 少得多 - 特别是如果您试图使您的对象不可变 - 这是一件好事（但并不总是最好的选择） - 但即使不是。
几个月前我一直在用java编程，我了解到我们应该只在应用程序需要时才使用getter和setter
玩得开心 ：）