我并不真的认为他们是邪恶的。但我很想生活在一个除非真的需要，我才会用到它们的世界里。

上面我读到的一个例子是对代码进行未来验证。例如:

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。效果很好，没有损坏任何东西。

我并不真的认为他们是邪恶的。但我很想生活在一个除非真的需要，我才会用到它们的世界里。

上面我读到的一个例子是对代码进行未来验证。例如:

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。效果很好，没有损坏任何东西。

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

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

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

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

这是滑坡效应。

简单的Transfer对象(或Parameter对象)的唯一目的可能是保存某些字段，并根据需要提供它们的值。然而，即使在这种退化的情况下，也可以认为对象应该是不可变的——在构造函数中配置，并且只公开get…方法。

还有一个类暴露了一些“控制旋钮”;你的汽车收音机的UI可能被理解为公开类似getVolume、setVolume、getChannel和setChannel的东西，但它的真正功能是接收信号和发出声音。但是这些旋钮并没有暴露太多的实现细节;从这些接口特征上，你无法知道收音机是晶体管(主要是软件)还是真空管。

越是开始将对象视为问题域任务的积极参与者，就越会认为是要求它做一些事情，而不是要求它告诉您它的内部状态，或者要求它提供它的数据，以便其他代码可以使用这些值做一些事情。

所以…“邪恶”?不是真的。但每次你倾向于输入一个值并暴露它们都会得到。并设置…方法，问问自己为什么，以及该对象的真正职责是什么。如果你能给自己的唯一答案是，“为我保留这个值”，那么可能有OO之外的东西在这里。

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

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

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

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