为了简单的类而放弃 getter 和 setter 可以吗？

Question

我正在创建一个非常简单的类来表示 3D 空间中的位置。

目前，我只是让用户直接访问和修改各个 X、Y 和 Z 值。换句话说，它们是公共成员变量。

template <typename NumericType = double>
struct Position
{
    NumericType X, Y, Z;

    // Constructors, operators and stuff...
};

这背后的原因是，因为 NumericType 是一个模板参数，所以我不能依赖有一种体面的方法来检查值的完整性。 （我怎么知道用户不希望用负值表示位置？）因此，添加 getter 或 setter 来使界面复杂化是没有意义的，而且直接访问应该因其简洁性而受到青睐。

Pos.X = Pos.Y + Pos.Z; // Versus...
Pos.SetX(Pos.GetY() + Pos.GetZ());

这是良好实践的例外吗？我的代码的（假设的）未来维护者会追捕我并打我的脸吗？

Answer 1

使用 getter 和 setter 背后的想法是能够执行其他行为，而不仅仅是设置值。推荐这种做法是因为您可能想要在课堂上改进很多东西。

使用 setter 的常见原因（可能还有更多）：

• 验证：并非变量类型允许的所有值都对成员有效：分配之前需要验证。
• 不变量：依赖字段可能需要调整（例如，调整数组大小可能需要重新分配，而不仅仅是存储新大小）。
• 挂钩：在赋值之前/之后需要执行额外的工作，例如触发通知（例如在值上注册观察者/侦听器）。
• 表示：字段不以“发布”的格式存储为 getter 和 setter。该字段甚至可能不存储在对象本身中；该值可能会转发给其他一些内部成员或存储在单独的组件中。

如果您认为您的代码永远不会使用或需要上述任何内容，那么按原则编写 getter 和 setter 绝对不是一个好习惯。它只会导致代码膨胀。

编辑：与普遍的看法相反，使用 getter 和 setter 不太可能帮助您更改类的内部表示，除非这些更改很小。尤其是个人成员设置者的存在，使得这种改变变得非常困难。

Answer 2

如果 getter 和 setter 获取/设置您可能以多种方式实现的抽象值，那么它们实际上只是一个重要的设计选择。但是，如果您的类如此简单并且数据成员如此基本以至于您需要直接公开它们，那么只需将它们公开即可！你会得到一个漂亮、便宜的聚合类型，没有任何装饰，而且它是完全自我记录的。

如果您确实想要将数据成员设为私有，但仍授予对其的完全访问权限，只需将单个访问器函数重载一次，如 T & access() 并一次作为 const T &访问（）常量。

---

编辑：在最近的一个项目中，我只是使用元组作为坐标，并具有全局访问器函数。也许这可能有用：

template <typename T>
inline T cX(const std::tuple<T,T,T> & t) { return std::get<0>(t); }

typedef std::tuple<double, double, double> coords;
//template <typename T> using coords = std::tuple<T,T,T>; // if I had GCC 4.8

coords c{1.2, -3.4, 5.6};

// Now we can access cX(c), cY(c), cZ(c).

Answer 3

我花了一段时间，但我跟踪了这​​个旧的 Stroustrup 采访，他自己讨论了暴露数据结构与封装类： http://www.artima.com/intv/goldilocks3.html

更深入地了解细节，现有答案中可能缺少/低估了某些维度。封装的好处随着以下方面的增加而增加：

• 重新编译/链接依赖：大量应用程序使用的低级库代码，这些应用程序可能非常耗时和/或难以重新编译和重新部署
  • 如果实现不符合要求（这可能需要 pImpl 习惯用法和性能妥协），通常会更容易，因此您只需重新链接即可，如果您可以部署新的共享库并简单地弹回应用程序，情况会更容易
  • 相比之下，如果对象仅用于特定翻译单元的“非外部”实现，则封装的好处会大大减少
• 尽管实现存在波动，但接口稳定性：实现所在的代码更具实验性/ 易失性，但 API 要求很好理解
  • 请注意，通过小心，可以在使用 typedef 作为成员变量的类型时直接访问成员变量，这样就可以替换代理对象并支持相同的客户端代码使用调用不同的实现

Answer 4

如果你做了一些非常简单的事情，你的解决方案可能就很好。

如果您后来意识到球坐标系中的计算更容易或更快（并且您需要性能），那么您可以信赖这一点。

Answer 5

对于这样的众所周知的结构来说是可以的：

1. 可以有任何可能的值，比如 int；
2. 出于性能原因，在操作其值时应像内置类型一样操作。

但是，如果您需要的不仅仅是“只是 3D 向量”的类型，那么您应该将其包装在另一个类中，作为私有成员，然后通过成员函数和附加功能成员函数公开 x、y 和 z。

Answer 6

这背后的原因是，因为 NumericType 是一个模板参数，所以我不能依赖有一种体面的方法来检查值的完整性。 （我怎么知道用户不希望用负值表示位置？）

语言和编译器很好地支持这种情况（通过专门化）。

因此，添加 getter 或 setter 来使接口复杂化是没有意义的，直接访问应该因其简洁性而受到青睐。

没有实际意义的争论——见上文。

这是良好实践的例外吗？

我不认为是这样。您的问题意味着验证应该存在，但不值得实现/支持，因为您选择在实现中使用模板，并且不专门适合您的语言功能已经选择了。通过这种方法，接口似乎只得到部分支持——那些缺少的实现只会污染客户端的实现。