什么时候在 OOP 中使用友谊是明智的？

Question

我目前正在阅读 http://www.cplusplus.com 教程，我在这里看到了本节: http://www.cplusplus.com/doc/tutorial/inheritance.html 涉及 C++ 中的友元函数和友元类主题。

我的问题是，什么时候创建程序时使用友谊是明智的？

我得到的唯一线索是文章中的一个示例，该示例演示了“复制”对象的友元函数。

Answer 1

Marshall Cline 的 C++ FAQ Lite 中有一些非常好的经验法则。

整个事情都很好，但请特别注意 “好友是否违反封装？ “ 有关使用它们的正确方法以及何时最好划分类并声明它们为朋友的示例。

Answer 2

友元函数的存在是为了将自由函数呈现为类接口的连续部分。 在某些地方，自由函数是类接口的一部分。 示例：假设您有一个任意精度的类 BigNum。 以下是友元函数的一些明显候选者：

// binary operators where BigNum isn't the left-hand operand
BigNum operator+ (int, BigNum);
BigNum operator- (int, BigNum);

// stream operators
std::ostream &operator<< (std::ostream &os, const BigNum &num);
std::istream &operator>> (std::istream &is, BigNum &num);

现在，给出这两个示例，在许多情况下，二元运算符不需要是友元（例如，我可以通过委托给 来实现 int + BigNum BigNum + int，它是一个成员函数，因此已经具有完全访问权限）。 但这完全取决于您对性能的需求，以及您愿意通过类的公共成员函数公开什么。

Answer 3

Memento 设计模式是好友类的一个很好的应用。

Answer 4

由于朋友通常会违反数据隐藏机制，因此只能在真正需要时才使用它们。 如果你的设计严重依赖朋友，那么它可能在某种程度上是错误的。

当你离不开朋友的一个例子是覆盖 << 和>> 流运营商。 此外，友元类经常用于某些设计模式的实现 - 我想到了“迭代器”。

Answer 5

我只使用友元方法和属性在类本身中用于克隆自身或将另一个对象分配给自身。 这在很大程度上被取代了，我们重构了设计以在我们的设计中实现纪念品设计模式。

备忘录是通过用于保存和加载对象的相同机制创建的。 即，备忘录创建一个流，对象写入该流，并且备忘录可以传递给同一类的任何其他对象，以使其成为创建备忘录的对象的精确副本。

有时，在某些情况下，对象需要非常紧密地一起工作，在这种情况下，我通过将它们聚合在另一个对象后面来简化它们的交互。 作为“友元”变量且仅对其他对象可见的变量对于进行聚合的类是私有的。