何时在 C++ 中使用友元类

发布于 2024-07-13 11:05:45 字数 436 浏览 10 评论 0原文

可能的重复：
什么时候应该在 C++ 中使用“friend”？

我正在复习在我的 C++ 中（我是一名 Java 开发人员），我遇到了我已经忘记了一段时间的 friend class 关键字。这是厨房水槽的一部分功能之一，还是有充分的理由这样做，而不仅仅是一个普通的吸气剂？我理解其中的区别，因为它限制了谁可以访问数据，但我想不出有必要这样做的场景。

注意：我见过类似的问题，但我具体要问的是，这只是一个高级功能，除了让人们在看你的代码时感到困惑直到他们意识到你在做什么之外，没有任何实际价值吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

戴着白色围巾的女孩 2024-07-20 11:05:45

我同意这样的评论：如果使用得当，friend 关键字可以改善封装。我只是补充一点，友元类最常见（合法！）的用途可能是测试。您可能希望测试人员类比其他客户端类具有更大程度的访问权限。测试人员类可能有充分的理由查看故意对其他类隐藏的内部细节。

回复收藏 0 原文

满身野味 2024-07-20 11:05:45

根据我的经验，与使用友元（或可变，有点相似）来实际增强数据封装的情况相比，它用于破坏封装的情况很少见。

它对我来说很少有用，但是当我使用它时，它是在我必须将以前是单个类的类拆分为两个需要访问一些公共数据/功能的单独类的情况下。

编辑回应Outlaw Programmer的评论：我们绝对同意这一点。除了拆分类后将类交友之外，另一种选择是创建公共访问器，这有时会破坏封装！我认为有些人认为友好的类在某种程度上破坏了封装，因为他们经常看到它被错误地使用，并且许多人可能从未见过它被正确使用的代码，因为这是一种罕见的事情。不过，我喜欢你的表述方式——友好是一个很好的中间立场，介于不允许你分裂你的班级和让一切都向公众开放之间。

编辑回应 David Thornley：我同意 C++ 允许你做这样的事情的灵活性是 C++ 设计决策的结果。我认为这使得了解灵活语言中通常好的和坏的风格变得更加重要。 Java 的观点是，您永远不应该拥有友元类，因此不会提供这些友元类，但作为 C++ 程序员，我们作为社区有责任定义这些非常灵活但有时被误用的语言结构的适当使用。

编辑回应 Tom： Mutable 并不一定会破坏封装，但是我在现实生活中看到的 mutable 关键字的许多使用都破坏了封装，因为看到人们用 mutable 破坏封装比使用 mutable 破坏封装更常见实际上首先找到并理解 mutable 的正确用法。

回复收藏 0 原文

一人独醉 2024-07-20 11:05:45

当您希望一个类（Factory）负责创建另一类（Type）的实例时。您可以将 Type 的构造函数设为私有，从而确保只有 Factory 可以创建 Type 对象。当您希望将检查委托给可以充当验证器的其他类时，它非常有用。
只是一种使用场景。

PS 确实缺少 C# 中的“friend”关键字...

回复收藏 0 原文

傲影 2024-07-20 11:05:45

一个具体的实例是类工厂，您希望一个类只能通过另一个工厂类创建，因此您将构造函数设为私有，并将工厂类设为生成类的友元。

它有点像 2 英寸 12 点 3/4 英寸驱动套筒 - 不太常见，但当您需要它时，您会非常高兴拥有它。

回复收藏 0 原文

痴者 2024-07-20 11:05:45

有助于Memento 设计模式

回复收藏 0 原文

起风了 2024-07-20 11:05:45

关于好友的常见问题解答部分：此处

关于好友的常见问题解答部分：< a href="http://yosefk.com/c++fqa/fqa.html#fqa-friend" rel="nofollow noreferrer">此处

关于朋友的两种不同观点。

回复收藏 0 原文

瞳孔里扚悲伤 2024-07-20 11:05:45

我将 friend 结构视为应该在极少数情况下使用的语言功能之一，但这并不意味着它毫无用处。有几种模式需要创建 friend 类，其中许多已经位于此站点右侧的“相关”栏中。 ====>

回复收藏 0 原文

暗藏城府 2024-07-20 11:05:45

当您有多个类和/或函数一起工作以提供相同的抽象或接口时，就会使用友谊。典型的例子是实现某种数值类，所有非成员运算符函数（*、-、+、<<等）都被赋予友谊，以便它们可以处理数值类的私有数据。

这样的用例有点罕见，但确实存在，而且朋友非常有用。

回复收藏 0 原文

萤火眠眠 2024-07-20 11:05:45

我确信，这是几个示例中的一个，其中可以合法地使用友元类，而无需忽略封装的原因。

MyClass继承自GeneralClass。 MyClass已经变大了，所以你创建了HelperClass来封装MyClass的一些功能。然而，HelperClass 需要访问 GeneralClass 中的一些受保护函数才能正确执行其功能，因此您使 HelperClass 成为 MyClass 的友元。

这比公开受保护的函数要好，因为它们不需要对每个人都可用，但它有助于以 OOP 方式组织代码，以防止 MyClass 变得过于复杂。这是有道理的，因为虽然 HelperClass 并没有通过继承与 MyClass 具体相关，但它确实与 MyClass 有某种逻辑联系，体现在代码和设计中，作为“朋友”。

回复收藏 0 原文

挽你眉间 2024-07-20 11:05:45

我总是（并且只）使用朋友来对私有方法进行单元测试。我可以想象做到这一点的唯一其他方法是使用大量测试方法加载公共接口，这太混乱了，所以我更喜欢将测试方法隐藏在单独的测试类中。

像这样的事情：

class cMyClassTest;

class cMyClass
{
public:
.....

private:
friend cMyClassTest;
int calc();     // tricky algorithm, test carefully

};

class cMyClassTest
{
public:
int test_calc()
{
    cMyClass test;
    ....
    int result = test.calc();

    if( result == 42 )
        return 1;
    return 0;
}
};

I always ( and only ) use friend for unit testing private methods. The only other way I can imagine to do this would be to load up the public interface with a whole lot of testing methods, which is just too messy and so I prefer to hide the test methods in a seperate test class.

Something like this:

class cMyClassTest;

class cMyClass
{
public:
.....

private:
friend cMyClassTest;
int calc();     // tricky algorithm, test carefully

};

class cMyClassTest
{
public:
int test_calc()
{
    cMyClass test;
    ....
    int result = test.calc();

    if( result == 42 )
        return 1;
    return 0;
}
};

回复收藏 0 原文