我目前正在阅读http://www.cplusplus.com教程,我在这里遇到了这个部分:http ://www.cplusplus.com/doc/tutorial/inheritance.html 处理朋友功能的主题和C++ 中的朋友类。
我的问题是,什么时候在创建程序时谨慎使用友谊?
我得到的唯一线索是在文章中的一个示例中,该示例演示了一个“复制”对象的友元函数。
我目前正在阅读http://www.cplusplus.com教程,我在这里遇到了这个部分:http ://www.cplusplus.com/doc/tutorial/inheritance.html 处理朋友功能的主题和C++ 中的朋友类。
我的问题是,什么时候在创建程序时谨慎使用友谊?
我得到的唯一线索是在文章中的一个示例中,该示例演示了一个“复制”对象的友元函数。
Marshall Cline 的C++ FAQ Lite中有一些非常好的经验法则。
整个事情都很好,但特别是“朋友违反封装吗?” 有关正确使用它们的示例以及何时最好拆分类并将它们声明为朋友。
友元函数的存在是为了将自由函数呈现为类接口的连续部分。在某些地方,自由函数是类接口的一部分。示例:假设您有一个任意精度的类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
通过委托 to 来实现BigNum + int
,它是一个成员函数,因此已经具有完全访问权限)。但这一切都取决于您对性能的需求,以及您愿意通过类的公共成员函数公开什么。
朋友类的一个很好的应用是Memento设计模式。
由于朋友通常会违反数据隐藏机制,因此只能在真正需要时使用。如果您的设计严重依赖朋友,那么它可能在某种程度上是错误的。
一个不能没有朋友的例子是重写 << 和 >> 流操作符。此外,友元类经常用于一些设计模式的实现——我想到了“迭代器”。
I only used friend methods and properties for use within the class itself for clone itself or assigning another object to itself. That was largely superseded we refactored the design to implement of the Memento Design pattern in our design.
The Memento is created by the same mechanisms used to save and load the object. i.e. the Memento creates a stream, the object writes to it, and the memento can be passed to any other object of the same class to make it an exact duplicate of the object creating the memento.
Sometimes there are cases when objects need to work really close together in which case I simplify their interaction by aggregating them behind another object. Variables that would be "friend" variables and only visible to the other objects are private to the class doing the aggregating.