C++友谊与传承

Question

我知道友谊不是遗传的。我问自己：为什么？为什么C++设计者决定不让友谊被继承？你觉得友谊传承有用吗？我自己的答案是肯定的：就像 B 是 A 的朋友一样，我想让整个类家族成为 A 的朋友（B 及其衍生物）。也许，人们应该能够说：让仅 B 成为 A 的友元，或者让 B 及其派生类成为 A 的友元

。 我不知道为什么你们很多人认为我是在要求自动延长友谊。我更感兴趣的是程序员是否可以使用某种机制（不是自动的）将友谊扩展到整个家庭。

Answer 1

friend 声明在Friendly和Trusting之间创建了牢固的关系：

• 它将Friendly与Trusting的表示联系起来，因为它可以完全访问其内部，
• 这意味着Friendly发誓维护该类信任的不变量

因此，确保清楚地确定确切的范围似乎是一种很好的做法，这是继承无法实现的：会出现泄漏。

但事实是，继承甚至不是必需的。实际上有两种选择，具体取决于友谊想要实现的目标。它们涵盖了我遇到过的任何场景。

Friendly 作为代理

在您的示例中，Friendly 的派生体可以简单地访问 Trusting 通过Friendly，从而让您可以在一组有限的位置控制Trusting 上发生的操作。

class Trusting { friend class Friendly; };

class Friendly { protected: void modifyTrusting(); };

modifyTrusting 的实现可能意味着虚拟调用（挂钩）来自定义行为，但无论这些挂钩如何，都需要 Friendly 来确保类不变量不会被破坏。

并非如此Trusting

在这种情况下，Trusting 通过锁定的方法仅打开其界面的一部分，并将密钥授予 友好。 Friendly 也可以将密钥授予它信任的类，但这并不重要......在任何情况下 Trusting 确保其不变量不会被破坏，而关键只是一种减少方法暴露的机制。

class Key { friend class Friendly; Key() {} ~Key() {} };

class Trusting { public: void doSomething(Key const&); };

class Friendly { protected: Key const& key() const; };

我必须承认，我确实偏爱后一种方法并经常使用它，因为它限制了 Friendly 对 Trusting 实现细节的暴露。它还清楚地记录了信任我们亲爱的友好访问的哪些部分。

Answer 2

昨天我看到一个有趣的保险杠贴纸：“我的岳母是一名旅行社......为了罪恶感旅行”。在人际关系中，友谊在某种程度上是遗传的。虽然这确实会引发有关 SO 朋友和家人的有趣笑话，但重要的是要记住，痛苦和痛苦是许多笑话的基础。

在 C++ 中，友谊不是继承的，因为开发人员预见到了这会造成多少痛苦和痛苦。

Answer 3

这是一个糟糕的主意。

友谊不会遗传，因为友谊导致朋友之间的紧密联系。如果所有派生类也自动成为友元，那么这将导致原始对象和所有继承类之间的紧密绑定。

紧耦合对于一起创建和维护的类来说是很好的。但是对于其他用户创建的类，紧密耦合会导致维护噩梦，并阻止您更改原始对象（因为所有紧密耦合的朋友都依赖于您的实现）。