Question

我知道友谊不是继承的。我问自己：为什么？为什么C ++设计师决定不让友谊继承？你是否发现友谊继承是一件有用的事情？我自己的答案是肯定的：就像B是A的朋友一样，我想让一整个班级成为A（B及其衍生物）的朋友。也许，应该可以说：让只 B成为A的朋友或让B 和其派生类成为A的朋友。

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

Answer 1

friend声明在友情和信任之间建立了牢固的关系：

它将友好链接到信任的表示，因为它可以完全访问其内部
这意味着友方发誓维护信任的类别不变量

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

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

友情 作为代理

在您的示例中，Friendly的派生可以直接进入Trusting到Friendly，从而可以控制在Trusting个有限位置内发生的操作

class Trusting { friend class Friendly; };

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

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

不是信任

在这种情况下，Trusting仅通过锁定方法打开其部分界面，并将密钥授予Friendly。 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的实现细节的曝光。它还清楚地记录了Trusting亲爱的Friendly访问的哪些部分。

Answer 2

我昨天看到一个有趣的保险杠贴纸：“我的岳母是旅行社... 因为内疚旅行”。友谊在某种程度上是在人际关系中继承的。虽然这确实引起了有关SOs朋友和家人的有趣笑话，但重要的是要记住苦难和痛苦是许多笑话的基础。

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

Answer 3

这是一个糟糕的主意。

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

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

C ++友谊和继承

3 个答案: