c++中的友元(friend)函数和类有什么用_c++破坏封装的正确姿势【详解】-C++-PHP中文网

c++中的友元(friend)函数和类有什么用_c++破坏封装的正确姿势【详解】

穿越時空

发布： 2025-12-21 19:17:02

原创

115人浏览过

友元不是破坏封装，而是封装机制的精细调节阀；它在严格控制下为可信协作者提供有限访问权限，用于无法通过公有接口高效实现的场景，如流操作符重载。

c++中的友元(friend)函数和类有什么用_c++破坏封装的正确姿势【详解】

友元不是破坏封装，而是在严格控制的前提下，为特定需求提供有限的访问权限。它不违背封装原则，而是封装机制的一部分——封装的目标是隐藏实现细节、保护数据安全，而不是把所有东西都锁死。友元恰恰是在“谁可以看”“看到多少”上做了精准授权。

友元函数：让非成员函数访问私有成员

当某个操作逻辑上不属于类的职责，但又必须读写其私有数据时（比如重载输入输出流），用成员函数反而会污染类接口。这时友元函数就派上用场。

声明方式：在类内部用 friend 关键字 + 函数原型，不加作用域，也不影响函数定义位置
常见用途：operator 和 operator>> 重载、比较函数、序列化辅助函数
注意：友元函数不是类的成员，没有 this 指针，必须显式传入对象或引用

友元类：授予整个类对私有成员的访问权

适用于两个类存在紧密协作关系，且这种关系是设计上明确、稳定、受控的。例如容器类与它的迭代器类、工厂类与被创建的具体类。

声明方式：在类内写 friend class ClassName;，被声明的类所有成员函数都能访问该类私有成员
单向性：A 声明 B 为友元，只表示 B 能访问 A 的私有内容，A 不能因此访问 B 的私有内容
慎用：友元类比友元函数权限更大，一旦滥用会显著扩大信任边界，应确保双方耦合是必要且最小化的

友元的正确使用原则

友元不是后门，而是经过设计评审的“授权通道”。是否该用，关键看三点：

立即学习“C++免费学习笔记（深入）”；

钉钉 AI 助理

钉钉AI助理汇集了钉钉AI产品能力，帮助企业迈入智能新时代。

204

查看详情

该功能是否真的无法通过公有接口高效/安全地实现？（比如深拷贝构造中需要直接读取另一对象的私有缓冲区）
访问者是否属于该类的“可信协作者”，而非任意外部代码？（如 std::string 的私有分配器接口只对 std::allocator 特化开放）
是否已考虑替代方案？比如增加受控的公有 getter/setter、提供回调接口、或重构职责划分

一个典型且合理的例子

实现一个自定义字符串类 MyString，想支持 std::cout 输出：

class MyString {
    char* data_;
    size_t len_;
public:
    MyString(const char* s) : len_(s ? strlen(s) : 0), data_(new char[len_+1]) {
        if (s) strcpy(data_, s);
    }
    ~MyString() { delete[] data_; }
<pre class="brush:php;toolbar:false;">// 友元函数：不属类，但需读私有成员
friend std::ostream& operator<<(std::ostream& os, const MyString& s) {
    return os << (s.data_ ? s.data_ : "");
}

登录后复制

};

这里不用成员函数，因为 operator 左操作数是 std::ostream，无法改成成员；也不该暴露 data_ 给所有人——只授权给这个特定的流输出函数即可。

基本上就这些。友元不是封装的漏洞，而是封装的精细调节阀。用得准，它让接口更干净、性能更优、协作更自然；用得滥，才真成隐患。关键不在“能不能用”，而在“为什么非用不可”。

以上就是c++++中的友元(friend)函数和类有什么用_c++破坏封装的正确姿势【详解】的详细内容，更多请关注php中文网其它相关文章！