大规模使用迈耶的建议来选择非会员、非好友功能？

Question

一段时间以来，我一直将类接口设计得最小化，与成员函数相比，我更喜欢命名空间包装的非成员函数。基本上遵循 Scott Meyer 在文章非成员函数如何改进封装中的建议。

我在一些小规模项目中这样做并取得了良好的效果，但我想知道它在更大范围内的效果如何。是否有任何大型的、备受推崇的开源 C++ 项目可供我查看，或许可以参考一下强烈遵循此建议的地方？

更新：感谢您提供的所有意见，但我对意见并不真正感兴趣，而是想知道它在更大范围内的实践中效果如何。尼克的答案在这方面最接近，但我希望能够看到代码。对实际经验（积极的、消极的、实际考虑等）的任何形式的详细描述也是可以接受的。

Answer 1

优先选择非成员非友元函数进行封装 除非您希望隐式转换适用于类模板非成员函数（在这种情况下，您最好将它们设为友元函数）：

也就是说，如果您有一个类模板 type:

template<class T>
struct type {
  void friend foo(type<T> a) {}
};

和一个可隐式转换为 type 的类型，例如：

template<class T>
struct convertible_to_type {
  operator type<T>() { }
};

以下内容按预期工作：

auto t = convertible_to_type<int>{};
foo(t);  // t is converted to type<int>

但是，如果您将 foo 设为非友元函数：

template<class T>
void foo(type<T> a) {}

那么以下内容不起作用：

auto t = convertible_to_type<int>{};
foo(t);  // FAILS: cannot deduce type T for type

由于您无法推导出 T，则函数 foo 从重载决议集中移除，即：没有找到函数，这意味着隐式转换不会触发。

Answer 2

我在我从事的项目中经常这样做；我现在公司最大的有2M行左右，但不是开源的，所以无法提供参考。不过，总的来说，我会说我同意这个建议。您将不严格包含在一个对象中的功能与该对象分离得越多，您的设计就会越好。

举例来说，考虑经典的多态性示例：具有子类的 Shape 基类和虚拟 Draw() 函数。在现实世界中，Draw() 需要获取一些绘图上下文，并可能了解正在绘制的其他事物或一般应用程序的状态。一旦将所有这些放入 Draw() 的每个子类实现中，您可能会出现一些代码重叠，或者大部分实际的 Draw() 逻辑将位于基类中或其他地方。然后考虑一下，如果您想重用其中一些代码，则需要提供更多的接口入口点，并且可能会用与绘制形状无关的其他代码污染函数（例如：多形状绘制相关逻辑） ）。不久之后，它就会变得一团糟，你会希望有一个绘制函数，它采用 Shape（以及上下文和其他数据），而 Shape 只是具有完全封装的函数/数据，而不使用或引用外部物体。

无论如何，这就是我的经验/建议，无论其价值如何。

Answer 3

我认为，随着项目规模的增加，非成员职能的好处也会增加。标准库容器、迭代器和算法库证明了这一点。

如果您可以将算法与数据结构解耦（或者，换句话说，如果您可以将对象的操作与其内部状态的操作方式解耦），则可以减少类之间的耦合并更好地利用通用代码。

斯科特·迈耶斯并不是唯一支持这一原则的作者。 Herb Sutter 也有，特别是在 Monoliths Unstrung 中，结尾与指导方针：

在可能的情况下，更喜欢以非成员非朋友的身份编写函数。

我认为该文章中不必要的成员函数的最佳示例之一是 std::basic_string::find;实际上，它没有理由存在，因为 std::find 提供了完全相同的功能。

Answer 4

OpenCV 库就是这样做的。他们有一个 cv::Mat 类来呈现 3D 矩阵（或图像）。然后他们拥有 cv 命名空间中的所有其他函数。

OpenCV 库非常庞大，并且在其领域受到广泛重视。

Answer 5

以非成员非友元形式编写函数的一个实际优点是，这样做可以显着减少彻底测试和验证代码所需的时间。

例如，考虑序列容器成员函数 insert 和 push_back。至少有两种方法来实现 push_back：

1. 它可以简单地调用 insert （无论如何，它的行为是根据 insert 定义的）
2. 它可以insert 会执行的所有工作（可能调用私有辅助函数），而无需实际调用 insert

显然，在实现序列容器时，您可能希望使用第一种方法。 push_back 只是 insert 的一种特殊形式，并且（据我所知）您无法通过实现 push_back 真正获得任何性能优势其他方式（至少不适用于 list、deque 或 vector）。

但是，要彻底测试这样的容器，您必须单独测试 push_back：由于 push_back 是一个成员函数，它可以修改容器的任何和所有内部状态。从测试的角度来看，您应该（必须？）假设 push_back 是使用第二种方法实现的，因为它有可能使用第二种方法实现。不保证它是按照insert 实现的。

如果 push_back 实现为非成员非友元，则它无法触及容器的任何内部状态；它必须使用第一种方法。当您为它编写测试时，您知道它不能破坏容器的内部状态（假设实际的容器成员函数已正确实现）。您可以利用这些知识来显着减少充分执行代码所需编写的测试数量。

Answer 6

（我没有时间把这个写得很好，下面是一个 5 分钟的大脑转储，毫无疑问可以在各种琐碎的层面上进行分解，但请说明概念和总体主旨。）

我对乔纳森·格林斯潘（Jonathan Grynspan），但想对此多说一点，而无法在评论中合理地做到这一点。

首先——对阿尔夫·斯坦巴赫说得好，他插话道：“这只是对他们观点的过度简化的讽刺，可能看起来是相互冲突的。无论如何，我在这个问题上不同意斯科特·迈耶斯的观点；因为我认为他在这里过于概括了，或者说他确实是这样。”

斯科特、赫伯等人在提出这些观点时，很少有人理解其中的权衡或替代方案，而且他们的力度不成比例。分析了人们在代码演化过程中遇到的一些令人烦恼的麻烦，并合理地导出了解决这些问题的新设计方法。让我们回到稍后是否有缺点的问题，但首先 - 值得一提的是，所讨论的痛苦通常很小且不常见：非成员函数只是设计可重用代码的一个小方面，并且在企业级系统中我已经仅仅编写与非成员一样放入成员函数中的相同类型的代码很少足以使非成员可重用。对他们来说，表达既复杂到值得重用，又不与它们设计的特定类紧密结合的算法是相当罕见的，这很奇怪，以至于几乎无法想象其他类会在支持相同的操作和语义。通常，您还需要模板参数，或引入基类来抽象所需的操作集。两者对性能、内联与外联、客户端代码重新编译都有重大影响。

也就是说，如果操作是根据公共接口实现的，并且作为非朋友非成员系统地强制执行，则在更改实现时所需的代码更改和影响研究通常会较少。但有时，它会使最初的实现变得更加冗长，或者以其他方式变得不太理想和可维护。

但是，作为试金石 - 这些非成员函数中有多少与它们当前适用的唯一类位于同一标头中？有多少人希望通过模板（这意味着内联、编译依赖项）或基类（虚拟函数开销）抽象其参数以允许重用？两者都阻止人们将它们视为可重用的，但如果情况并非如此，类上可用的操作非本地化，这可能会挫伤开发人员对系统的看法：开发人员通常必须自己解决问题相当令人失望的事实是——“哦——这只适用于 X 类”。

底线：大多数成员函数都不可重用。许多公司代码没有被分解为干净的算法和有可能重用前者的数据。这种划分在未来 20 年是没有必要的，也没有用处，也没有想象中有用。它与 get/set 方法非常相似 - 在某些 API 边界上需要它们，但当代码的所有权和使用本地化时，它们可能会造成不必要的冗长。

就我个人而言，我对此没有采取全有或全无的方法，而是根据潜在的可重用性与接口的局部性是否有任何可能的好处来决定将什么设为成员函数或非成员函数。

Answer 7

我也经常这样做，这似乎很有意义，而且它绝对不会导致缩放问题。 （虽然我当前的项目只有 40000 LOC）事实上，我认为它使代码更具可扩展性 - 它精简了类，减少了依赖性。
有时，它需要您重构您的函数，使它们独立于类的成员 - 从而通常创建一个更通用的辅助函数库，您可以在其他地方轻松地重用它。我还要提到，许多大型项目的常见问题之一是类的膨胀 - 我认为更喜欢非成员、非友元函数在这里也有帮助。