C++友谊与继承

Question

我知道友谊不是继承下来的。我在问自己:为什么？为什么C++设计师决定不让友谊被继承？你认为友谊传承会是一件有用的事情吗？我自己的回答是肯定的:就像B是A的朋友一样，我想让整个班级成为A (B及其导数)的朋友。也许，我们应该说:让只让B成为A的朋友，或者让B和的派生类成为A的朋友。

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

Answer 1

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的实现细节上。它还清楚地记录了Trusting的哪些部分--我们亲爱的Friendly访问。

Answer 2

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

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

Answer 3

这是个糟糕的主意。

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

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