这样做的原因是，如果您更改 的实现getData()，则不必更改直接访问的其余代码data。
而且，无论如何，一个智能编译器都会内联它（它总是知道类中的实现），所以没有性能损失。
这取决于。使用访问器函数提供了一个抽象层，这可以使未来对“数据”的更改不那么痛苦。例如，如果您想懒惰地计算“数据”的值，您可以将该计算隐藏在访问器函数中。
至于开销 - 如果您指的是性能开销，它可能是微不足道的 - 您的访问器几乎肯定会被内联。如果您指的是编码开销，那么是的，这是一种权衡，您必须决定是否值得为提供访问器付出额外的努力。
就个人而言，我认为在大多数情况下访问器不值得。
是的，我认为应该或多或少无条件地这样做。如果状态变量在某个基类中，它应该或多或少总是私有的。如果您允许它被保护或公开，所有继承的将直接使用它。这些类又可能是您的同事在其他项目中编写的类。如果您突然决定在基类中进行模拟并将变量名称重构为更合适的名称，则必须重写该状态的所有用户。
如果您是唯一的程序员或开发一些没人会使用的代码，这可能不是问题。但是一旦子类的数量开始增长，它可能会变得非常棘手。一定要爱透明！
然而，我不是这个星球上最好的孩子。有时我会作弊；）当你在所有者类中时，我认为直接访问私有数据是可以的。它甚至可能是有益的，因为您自动知道您正在修改您所在的实际类。鉴于您有某种命名约定实际上告诉您，例如一些带有下划线的变量名称末尾：“someVariable_ ”。
干杯！
嗯，Khunt 先生，在大多数情况下，开销对于访问者来说真的是微不足道的。问题是是否需要调用访问器逻辑，或者您是否需要直接访问该字段。这是每个单独实现的问题，但在许多情况下，不会有太大的不同。
访问器的真正原因是将您的字段封装到其他类 - 而不是包含类。
就个人而言，我不喜欢有几十个额外的函数（每个成员变量都获取和设置）。我只会使用data ，并且只有在需要做不同的事情时才会更改为getData() 。由于我们讨论的是仅在一个类中更改代码，因此应该不会太难。
我想这取决于您最终可能对您的数据成员做什么。
通过将其包装在访问器中，您可以执行诸如延迟检索数据之类的操作，如果这是一个昂贵的过程，而不是您不想做的事情，除非有人要求。另一方面，您可能知道它始终是一个愚蠢的内置类型，所以我看不出在那里通过访问器有什么好处。正如我所说，这取决于成员。
在我看来，这个问题最重要的方面是它是否使代码更具可读性并因此可维护？我个人认为不会，所以我不会这样做。
当然，您永远不应该为此添加私有访问器，那将是胡说八道。