我一直在阅读c++常见问题，对朋友声明很好奇。我个人从未使用过它，但我对探索这门语言很感兴趣。
使用friend的一个好例子是什么?
读了一些常见问题，我喜欢<< >>操作符重载和添加作为这些类的朋友的想法。然而，我不确定这如何不会破坏封装。什么时候这些异常可以保持在OOP的严格范围内?
当前回答
在工作中，我们广泛地请朋友来测试代码。这意味着我们可以为主应用程序代码提供适当的封装和信息隐藏。但我们也可以有单独的测试代码，使用朋友来检查内部状态和数据进行测试。
可以说，我不会将friend关键字作为设计的重要组成部分。
其他回答
在我之前工作过的一家公司里，我们遇到了一个有趣的问题，我们用朋友来产生良好的影响。我在我们的框架部门工作，我们在自定义操作系统上创建了一个基本的引擎级系统。在内部我们有一个类结构:
Game
/ \
TwoPlayer SinglePlayer
所有这些类都是框架的一部分，由我们的团队维护。该公司所制作的游戏便是基于这一源自games子游戏的框架。问题是Game有各种单人和双人玩家需要访问的东西的接口，但我们不想在框架类之外公开。解决方案是将这些接口设为私有，并允许双人和单人玩家通过友谊访问它们。
事实上，这整个问题本可以通过更好地实施我们的系统来解决，但我们被锁定在我们所拥有的东西上。
在做TDD的时候，我经常使用c++中的'friend'关键字。朋友能知道我的一切吗?
不，这只是一种单向的友谊。
对于操作符<<和操作符>>，没有很好的理由让这些操作符成为朋友。它们确实不应该是成员函数，但它们也不需要是朋友函数。
最好的方法是创建公共打印(ostream&)和读取(istream&)函数。然后，根据这些函数写出操作符<<和操作符>>。这提供了额外的好处，允许您将这些函数设置为虚拟函数，从而提供虚拟序列化。
简短的回答是:在friend确实可以改善封装时使用它。提高可读性和可用性(操作符<<和>>是典型的例子)也是一个很好的理由。
至于改进封装的例子，专门设计用于处理其他类的内部结构的类(想到了测试类)是很好的候选。
c++的创建者说这并没有破坏任何封装原则，我将引用他的话:
“朋友”是否违反封装? 不。但事实并非如此。“好友”是一种授予访问权限的显式机制，就像会员资格一样。你不能(在符合标准的程序中)在不修改类源的情况下授予自己对类的访问权。
很明显…
