谢谢，这真的澄清了我的想法。现在有10个（几乎）不使用getter和setter的好理由：

当您意识到您需要做的不仅仅是设置和获取值时，您可以将字段设为私有，这会立即告诉您直接访问它的位置。在那里执行的任何验证都只能是上下文无关的，而实际上很少进行这种验证。您可以更改设置的值-当调用者传递给您一个他们（震惊恐惧）希望您按原样存储的值时，这绝对是一场噩梦。你可以隐藏内部表示-太棒了，所以你要确保所有这些操作都是对称的，对吗？你已经将你的公共界面与表单下的更改隔离开来——如果你在设计一个界面，但不确定直接访问某个东西是否可行，那么你应该继续设计。一些库期望这样做，但并不多——反射、序列化、模拟对象都能很好地处理公共字段。通过继承这个类，您可以覆盖默认功能——换句话说，您不仅可以隐藏实现，而且可以使其不一致，从而真正混淆调用者。

最后三个我要离开（N/A或D/C）。。。

代码不断演变。private非常适合需要数据成员保护的情况。最终，所有的类都应该是一种“小程序”，它有一个定义良好的接口，你不能只使用它的内部结构。

也就是说，软件开发并不是要设置课程的最终版本，就好像你在第一次尝试时按下了一些铸铁雕像一样。当你使用它时，代码更像粘土。它随着你的发展而发展，并进一步了解你正在解决的问题领域。在开发过程中，类之间可能会发生不应有的交互（您计划排除的依赖关系）、合并或拆分。因此，我认为争论归结为人们不想虔诚地写作

int getVar() const { return var ; }

所以你有：

doSomething( obj->getVar() ) ;

而不是

doSomething( obj->var ) ;

getVar（）不仅在视觉上很嘈杂，而且给人一种错觉，认为getingVar（（）在某种程度上是一个比实际更复杂的过程。如果你的类有一个passthrough setter，那么你（作为类编写者）如何看待var的神圣性对你的类的用户来说尤其令人困惑——那么你似乎在设置这些门来“保护”你坚持认为有价值的东西，（var的神圣性）但即使你承认，任何人只要进来并将var设置为他们想要的任何值，而你甚至不去偷看他们在做什么，那么var的保护就没有多大价值。

所以我按如下方式编程（假设采用“敏捷”类型的方法——即当我编写代码时不知道它将要做什么/没有时间或经验来规划一个复杂的瀑布式界面集）：

1） 从具有数据和行为的基本对象的所有公共成员开始。这就是为什么在我所有的C++“示例”代码中，你会注意到我到处使用结构而不是类。

2） 当对象对数据成员的内部行为变得足够复杂时（例如，它喜欢以某种顺序保存内部std:：list），就会编写访问器类型函数。因为我是自己编程的，所以我并不总是立即将成员设置为私有，但是在类的进化过程中，成员将被“提升”为受保护或私有。

3） 完全充实并对其内部有严格规则的类（即，它们确切地知道自己在做什么，你不能“操”（技术术语）它的内部）被赋予类名称，默认为私有成员，只有少数成员被允许公开。

我发现这种方法可以让我避免在一个类进化的早期阶段，当大量数据成员被迁移、转移等时，坐在那里虔诚地编写getter/setter。

原因有很多。我最喜欢的是当你需要改变行为或调整你可以设置的变量时。例如，假设您有一个setSpeed（intspeed）方法。但你希望你只能将最大速度设置为100。您可以执行以下操作：

public void setSpeed(int speed) {
  if ( speed > 100 ) {
    this.speed = 100;
  } else {
    this.speed = speed;
  }
}

现在，如果代码中的每个地方都使用公共字段，然后意识到需要上述要求，该怎么办？寻找公共领域的每一种用法，而不仅仅是修改你的setter。

我的2美分：）

我能想到一个原因，为什么你不希望一切都公开。

例如，您从未打算在类外部使用的变量可以被访问，甚至可以通过链变量访问（即object.item.origin.x）直接访问。

通过将所有内容都设为私有，并且仅将您想要扩展的内容以及可能在子类中引用的内容设为受保护的，并且通常只将静态最终对象设为公共，那么您就可以通过使用setter和getter访问您想要的程序内容来控制其他程序员和程序可以在API中使用什么，以及它可以访问什么，以及不能访问什么，或者可能是其他恰好使用您的代码的程序员，可以在您的程序中进行修改。

很多人都在谈论二传手和二传手的优点，但我想扮演魔鬼代言人的角色。现在我正在调试一个非常大的程序，程序员们决定让所有的东西都变得更好和更好。这看起来不错，但这是一场逆向工程噩梦。

假设你正在查看数百行代码，你会发现：

person.name = "Joe";

这是一段非常简单的代码，直到你意识到它是一个setter。现在，您遵循该setter，发现它还设置了person.firstName、person.lastName、person.isHuman、person.hasReallyCommonFirstName，并调用person.update（），后者将查询发送到数据库等。哦，这就是发生内存泄漏的地方。

乍一看就理解一段本地代码是具有良好可读性的一个重要特性，getter和setter往往会打破这一特性。这就是为什么我尽量避免使用它们，并在使用它们时尽量减少它们所做的事情。

编辑：我回答这个问题是因为有很多学习编程的人都在问这个问题，大多数答案在技术上都很好，但如果你是新手，就不那么容易理解了。我们都是新手，所以我想我会尝试一个更适合新手的答案。

两个主要的是多态性和验证。即使它只是一个愚蠢的数据结构。

假设我们有一个简单的类：

public class Bottle {
  public int amountOfWaterMl;
  public int capacityMl;
}

这是一个非常简单的类，它包含有多少液体，容量是多少（毫升）。

当我这样做时会发生什么：

Bottle bot = new Bottle();
bot.amountOfWaterMl = 1500;
bot.capacityMl = 1000;

嗯，你不会指望这会奏效，对吧？你想进行某种理智检查。更糟糕的是，如果我从未指定最大容量呢？哦，亲爱的，我们有问题。

但也有另一个问题。如果瓶子只是一种容器呢？如果我们有几个容器，所有容器都有容量和液体量，会怎么样？如果我们能做一个接口，我们就可以让程序的其他部分接受这个接口，而瓶子、偷工减料和各种各样的东西就可以互换使用了。那不是更好吗？由于接口需要方法，这也是一件好事。

我们最终会得到这样的结果：

public interface LiquidContainer {
  public int getAmountMl();
  public void setAmountMl(int amountMl);
  public int getCapacityMl();
}

太棒了现在我们把瓶子换成这个：

public class Bottle extends LiquidContainer {
  private int capacityMl;
  private int amountFilledMl;

  public Bottle(int capacityMl, int amountFilledMl) {
    this.capacityMl = capacityMl;
    this.amountFilledMl = amountFilledMl;
    checkNotOverFlow();
  }

  public int getAmountMl() {
    return amountFilledMl;
  }

  public void setAmountMl(int amountMl) {
     this.amountFilled = amountMl;
     checkNotOverFlow();
  }
  public int getCapacityMl() {
    return capacityMl;
  }

  private void checkNotOverFlow() {
    if(amountOfWaterMl > capacityMl) {
      throw new BottleOverflowException();
    }
}

我将把BottleOverflowException的定义作为练习留给读者。

现在请注意这是多么的强大。我们现在可以通过接受LiquidContainer而不是Bottle来处理代码中的任何类型的容器。这些瓶子是如何处理这种东西的呢。您可以有在磁盘发生变化时将其状态写入磁盘的瓶子，也可以有保存在SQL数据库或GNU知道其他内容的瓶子。

所有这些都可以有不同的方法来处理各种各样的百日咳。瓶子只是检查，如果它溢出，就会抛出RuntimeException。但这可能是错误的做法。（关于错误处理有一个很有用的讨论，但我有意保持非常简单。评论中的人可能会指出这种简单方法的缺点。；）

是的，我们似乎从一个非常简单的想法迅速得到更好的答案。

请注意，您不能更改瓶子的容量。它现在被镶嵌在石头上。您可以通过将int声明为final来实现这一点。但如果这是一个列表，你可以清空它，添加新的东西，等等。你不能限制接触内脏的权限。

还有第三件事不是每个人都解决过：getter和setter使用方法调用。这意味着它们看起来像其他地方的正常方法。DTO和其他东西没有奇怪的特定语法，而是到处都有相同的语法。