C++友谊和继承

我知道友谊不是遗传的。我在问自己：为什么？为什么C++设计师决定不让友谊继承？你发现友谊继承会是一件有用的事情吗？我自己的回答是肯定的：就像B是A的朋友一样，我想让整个家庭成为A（B及其衍生物）的朋友。也许，人们应该能够说：让只 B是一个的朋友或令B 和及其派生类是A.C++友谊和继承

诗的朋友。我不知道为什么你们中的很多人以为我是想要自动友谊的延伸。我更感兴趣的是程序员使用某种机制（不是自动）将友谊扩展到整个家庭的可能性。

来源

2011-09-17 luke

您还没有显示出引人注目的用例。就我个人而言，我看不到它的用处。在大多数情况下，您不需要继承友谊，因为您可以使用普通继承：函数'foo（A＆）'是'A'的朋友，当然也可以使用'B'类型的参数。 –

http://www.parashift.com/c++-faq-lite/friends.html#faq-14.4 – Mat

“Friend'ship的整个目的是为了表明两个具有强耦合的实体，允许友谊被继承和传播它沿着等级划分将打破朋友存在的基础，并打破OOP的原则。 –

一个friend声明创建的友好与信任之间的紧密关系：

它关系下的友好与信任的表现，因为它有其内部完全进入
这意味着友好发誓坚持信任的类不变式

因此，看起来很好的做法，以确保清楚地确定确切的范围，继承无法实现的东西：会有泄漏。

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

友好作为代理

在您的例子中，Friendly衍生物可以简单地通过Friendly伸入Trusting，从而让您控制在一组有限的地方上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实施细则。它还清楚地记录了我们亲爱的Friendly访问的哪个部分Trusting。

来源

2011-09-17 10:23:44

这是一个可怕的想法。

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

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

来源

2011-09-17 16:41:03

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

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

来源

2011-09-17 16:58:34

C++友谊和继承

回答

相关问题