什么是更好的做法？受保护/获取？

除了读取值之外，您还需要(或预计将来需要)做其他事情吗?例如:断言、锁定还是使读多态?

• 如果没有，则使用该字段。
• 如果是，使用getter

是否使用protected与此完全正交。

顺便说一句，像c#和Java这样的托管语言通常需要getter的存在，在"逻辑上"只要普通字段就足够了，因为它们的UI设计(和其他)工具都是这样实现的。因此，尽管c++中缺乏反射或此类工具，但过度使用getter的做法似乎已经"抹掉"了c++。

protected比private更接近public。人们可以创建派生类，访问和更改受保护的成员，并将其派生实例用作基类的实例。你可以在此基础上做决定。如果你想让一个数据成员对外界是只读的，你需要一个getter，而这是没有办法的。受保护的getter(也可能是setter)也可以工作。

另一件要注意的事情是，setter可以作为数据的网关。它们可用于验证范围并在需要时抛出异常。这一点也要考虑进去。

同样，由于您说它是由某个派生类使用的，您可能希望使该类为friend。这可能是个好主意，也可能不是个好主意，你应该仔细评估利弊。

我不认为getter和setter通常是糟糕的设计。我敢肯定它们会被滥用，就像几乎任何习语或模式一样。泛化从来不是个好主意⁽¹⁾

<一口>(1)是的。

受保护的公共接口(类、成员、字段)是您需要保持稳定的东西。每次更改受保护和公共接口时，都有可能破坏依赖于它的任何代码。

这可能是你自己的一行代码被你破坏了。在您自己的代码库中可能有数百个类。如果你公开发布你的代码，那么你可能会破坏来自数百个你从未听说过也从未见过的程序员的数千行代码。

有时候这种休息是必要的，也是好的。有时候，只要有一点远见就可以避免。养成理解和考虑改变的原因的习惯是优秀设计的核心。

如果getter和setter是糟糕的程序设计，为什么会这样?

getter和setter只提供了少量的封装。你仍然没有对用户隐瞒太多。它们仍然知道代码中存在这种类型的字段(或者至少知道您假装存在)，并且它们依赖于它的存在。如果您更改了类的实现，使该字段不再需要，则无法删除getter/setter，除非您愿意破坏所有依赖的代码。如果试图避免中断，就必须使这些访问器仍然工作并具有逻辑意义，这可能很困难。

有时公开字段(或Getter/Setter)是有意义的，即使在高级代码中也是如此。如果该字段对访问很重要，并且永远没有理由更改名称或类型(从使用您的代码的程序员的角度来看)，那么以某种方式公开它可能是好的，也是最好的。

有时候在Getter/Setter中包装字段是有意义的。如果您有getter/setter，则可以更容易地添加日志记录、边界检查、线程锁/信号量和调试器断点。在c++中，定义一个需要有Getter/Setter的抽象接口也比定义一个需要有字段的接口更容易。

有时直接暴露一个字段，而不使用getter/setter是有意义的。有时完全由字段组成的"类"是有意义的(考虑使用struct代替)。这在非常低级的代码中(例如从文件中提取数据的代码)或在另一个类的实现中(例如在算法的实现中)最为常见。通常你会把这些类隐藏在其他类中，所以你代码的用户永远不会看到它们。

我的老师告诉我总是使用getter，而其他人告诉我在任何级别使用getter都会暴露出糟糕的程序设计。真正的答案是什么?我觉得两者都是不合逻辑的极端。

概括性陈述往往具有真理，但真理很少是二元的。

养成问"为什么?"的习惯。养成自己判断事实的习惯，并在他们自己的背景下判断情况。有时候，在特定的情况下，"永远最好"的东西实际上并不是最好的，甚至根本不是最好的。

什么是类。数据集合还是行为集合?

当然都是。但是，让我们对比一下字段和访问方法(getter和setter)是如何使您能够处理数据和行为的。

字段/strong>

• 数据
• 你不能在不改变依赖类的情况下改变它们的行为(除非它们是指向抽象基类的指针)
• 可以通过操作符直接访问，因此可以在表达式中内联使用。
• 你不能像他们的名字一样聪明。它们通常不会与行为联系在一起。

访问器方法

<
• 是行为/gh>
• 你可以改变他们，而不必改变依赖类(假设你保持相同的合同)
• 你不能用操作符直接访问它们，所以不能在那么多表达式中直接使用(不需要做一些工作)。
• 你可以用它们做方法链接。
• 你可以尽可能聪明地使用它们基于动词的名称(Get, Create, Find等)。它们定义了一个行为。

正切:方法链接很简洁，因为它允许你创建所谓的"流畅接口"。