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

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

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

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

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

这取决于所讨论的编程语言。您的问题是在Java上下文中提出的，在Java上下文中，getter和setter似乎通常被认为是一件好事。

相反，在Python世界中，它们通常被认为是糟糕的风格:它们在代码中添加行，但实际上没有添加功能。当Python程序员需要时，他们可以使用元编程来捕获对象属性的获取和/或设置。

在Java(至少是我十年前学过的Java版本)中，这是不可能的。因此，在Java中最好严格地使用getter和setter，这样如果需要，就可以覆盖对变量的访问。

(这并不意味着Python一定比Java好，只是不同而已。)

他们绝对是邪恶的。

@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是非常非常邪恶的。它们本质上让您假装隐藏对象的内部，而大多数情况下您所做的一切都是在多余的代码中进行的，这些代码无法隐藏内部状态。对于一个简单的POJO，没有理由不能用obj.name = "Tom"替换getName()和setName()。

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

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

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

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