struct和class的核心区别在于默认访问权限：struct默认成员和继承均为public，class默认成员和继承均为private。这一差异使struct常用于数据聚合的POD类型，如Point、Color等轻量级结构，便于直接访问成员；而class更适用于封装复杂行为与状态的抽象对象，如Account、FileHandler，强调信息隐藏和接口控制。尽管二者在语法功能上完全等价，均可实现OOP全部特性，包括继承与多态，但使用class进行面向对象设计符合社区约定，能更好传达代码意图，避免因默认public带来的封装风险和理解歧义。因此，最佳实践是用struct表示简单数据结构，用class构建封装良好的抽象类型。
C++中
struct和
class在语法层面几乎可以互换，但它们在默认成员访问权限和默认继承权限上存在一个核心且根本的区别。简单来说，
struct默认所有成员（包括数据成员和函数成员）都是
public的，而
class默认所有成员都是
private的。同样，当一个
struct继承另一个类型时，默认是
public继承；而
class默认是
private继承。
在C++的世界里，
struct和
class这两个关键字，从功能上讲，它们的能力是完全对等的。你可以用
struct实现完整的面向对象编程，包括封装、继承和多态，反之亦然。但它们的设计初衷和社区约定，却让它们在实际应用中扮演了不同的角色，这主要就是由它们那点“默认”行为差异决定的。
解决方案
struct和
class的根本区别在于它们的默认访问修饰符。
对于
struct：
立即学习“C++免费学习笔记（深入）”；
-
默认成员访问权限是
public
。 这意味着如果你不明确指定，struct
内部的所有数据成员和成员函数都可以从外部直接访问。 -
默认继承权限是
public
。 当一个struct
从另一个struct
或class
继承时，如果未指定继承方式，则默认为public
继承。
对于
class：
-
默认成员访问权限是
private
。 这意味着如果你不明确指定，class
内部的所有数据成员和成员函数都只能在其内部访问，外部无法直接访问。 -
默认继承权限是
private
。 当一个class
从另一个struct
或class
继承时，如果未指定继承方式，则默认为private
继承。
这看起来只是一个小小的默认设置差异，但在编程实践中，它却深刻影响了我们如何选择使用它们。
struct通常被用来定义那些主要用于聚合数据、行为相对简单、或者希望其内部成员能被方便访问的“纯数据结构”。比如，一个表示坐标的
Point，或者一个表示日期的
Date，我们可能更倾向于用
struct，因为它们的成员通常就是数据本身，并且我们希望可以直接访问它们。
struct Point {
int x; // 默认 public
int y; // 默认 public
};
// 使用
Point p;
p.x = 10; // 可以直接访问
p.y = 20;而
class则更常用于实现复杂的、需要严格封装和信息隐藏的抽象类型，也就是我们常说的“对象”。我们希望通过
public接口来与对象交互，而其内部的数据和实现细节则通过
private或
protected来保护。
class Account {
double balance; // 默认 private
public:
void deposit(double amount) { // 显式 public
balance += amount;
}
double getBalance() const { // 显式 public
return balance;
}
};
// 使用
Account acc;
// acc.balance = 100; // 错误，balance是private
acc.deposit(100); // 通过public接口访问
double currentBalance = acc.getBalance();这种默认行为的选择，实际上是C++设计者在平衡C语言的兼容性（
struct在C语言中就是纯粹的数据聚合）和面向对象编程的需求（
class强调封装）之间做出的一个权衡。它提供了一种语义上的暗示，帮助开发者在阅读代码时，快速理解一个类型是更偏向于数据容器，还是一个功能完整的抽象实体。
C++为何同时保留struct和class？它们各自的最佳实践场景是什么？
C++同时保留
struct和
class，并非为了引入冗余，而是为了提供语义上的清晰度和向后兼容性，并引导开发者采纳更符合其意图的设计模式。
从历史角度看，
struct是C语言的遗产，它在C++中得以保留，确保了C代码的兼容性。在C语言中，
struct纯粹是数据的聚合体，没有成员函数，也没有访问权限的概念。C++在保留这一基本功能的同时，扩展了
struct，使其也能拥有成员函数、构造函数、析构函数、继承等所有
class的特性。
从语义角度看，这种区分是一种约定俗成的“最佳实践”：
-
struct
的最佳实践场景： 主要用于定义“Plain Old Data (POD)”类型或轻量级数据结构。当你的类型主要用于聚合一些相关的数据，并且这些数据通常需要被外部直接访问，或者它不包含复杂的业务逻辑，仅仅是一个数据载体时，使用struct
是更自然的选择。例如，表示几何坐标（Point
）、日期（Date
）、颜色（Color
）等。这些类型通常没有需要严格保护的内部状态，或者其行为就是围绕这些数据的简单操作。使用struct
可以减少代码量，因为它默认public
，你不需要为每个成员都写public:
。// 示例：一个简单的颜色结构 struct Color { unsigned char r, g, b, a; // 默认 public，方便直接访问 }; // 示例：一个链表节点 struct Node { int data; Node* next; // 默认 public，方便链表操作 }; -
class
的最佳实践场景： 主要用于定义复杂的抽象类型或行为丰富的对象。当你的类型需要封装内部状态、提供公共接口来控制其行为、隐藏实现细节、维护不变量、或者需要复杂的生命周期管理时，class
是更合适的选择。这符合面向对象编程（OOP）中“封装”的核心原则。例如，文件管理器（FileManager
）、数据库连接（DbConnection
）、图形用户界面组件（Button
）等。这些类型通常有需要保护的内部数据，并且通过公共方法提供受控的访问和操作。// 示例：一个文件操作类 class FileHandler { std::string filename; std::fstream fileStream; // 默认 private，隐藏文件流细节 public: FileHandler(const std::string& name) : filename(name) { /* 打开文件 */ } ~FileHandler() { /* 关闭文件 */ } bool writeLine(const std::string& line) { /* 写入逻辑 */ return true; } std::string readLine() { /* 读取逻辑 */ return ""; } };
这种约定并非强制，但它提供了一种视觉线索，让阅读代码的人能更快地理解作者的意图。看到
struct，我倾向于认为它是一个数据包；看到
class，我则会预期它是一个封装了行为和状态的抽象实体。
在继承和多态中，struct和class的行为有何异同？
在继承和多态的机制层面，
struct和
class的行为是完全相同的，它们之间没有本质区别。所有的继承规则、虚函数机制、多态行为等，对
struct和
class都一视同仁。它们唯一的差异仍然体现在默认的继承访问权限上。
-
默认继承权限：
struct
默认是public
继承。class
默认是private
继承。
这意味着如果你写：
struct BaseStruct { int x; };
struct DerivedStruct : BaseStruct { int y; }; // 默认 public 继承这里的
DerivedStruct默认以
public方式继承了
BaseStruct。
而如果你写：
class BaseClass { int x; };
class DerivedClass : BaseClass { int y; }; // 默认 private 继承这里的
DerivedClass默认以
private方式继承了
BaseClass。
这个默认差异的影响在于，
private继承意味着基类的
public和
protected成员在派生类中都变成了
private。这通常用于实现“has-a”关系（通过继承实现），而不是“is-a”关系，因为它切断了派生类对象作为基类对象使用的能力（即不能进行向上转型）。而
public继承则保留了这种能力，是实现多态的基础。
然而，请注意，这仅仅是默认行为。你完全可以通过显式指定继承方式来覆盖这些默认值：
// struct 也可以 private 继承
struct DerivedStructPrivate : private BaseStruct { /* ... */ };
// class 也可以 public 继承
class DerivedClassPublic : public BaseClass { /* ... */ };所以，在实现多态时，无论你使用的是
struct还是
class作为基类或派生类，只要你显式地使用了
public继承，并且基类中存在虚函数，那么它们就能正常地参与多态机制。例如：
struct Shape {
virtual void draw() const = 0; // 虚函数
virtual ~Shape() = default;
};
class Circle : public Shape { // public 继承，实现多态
public:
void draw() const override {
// 绘制圆形
}
};
class Rectangle : public Shape { // public 继承，实现多态
public:
void draw() const override {
// 绘制矩形
}
};
// 使用多态
std::vector shapes;
shapes.push_back(new Circle());
shapes.push_back(new Rectangle());
for (const auto& s : shapes) {
s->draw(); // 调用各自的 draw()
}
// 清理内存
for (const auto& s : shapes) {
delete s;
} 在这个例子中，
Shape可以是
struct也可以是
class，
Circle和
Rectangle也一样，只要继承方式是
public，并且有虚函数，多态就能正常工作。因此，在继承和多态的核心机制上，
struct和
class之间没有功能上的差异，差异仅在于它们对继承权限的默认设定。
将struct用于OOP设计是否可行？它会带来哪些潜在的风格问题？
从纯粹的技术能力上讲，将
struct用于完整的面向对象编程（OOP）设计是完全可行的。C++标准赋予了
struct与
class同等的能力，包括成员函数、构造函数、析构函数、继承、虚函数、访问修饰符等等。你可以用
struct来定义抽象基类，实现接口，甚至构建复杂的类层次结构。
然而，尽管技术上可行，但在实际的工程实践和代码风格上，这样做可能会带来一些潜在的风格问题和误解：
-
违背社区约定和语义期望： 这是最主要的问题。如前所述，C++社区普遍将
struct
视为数据聚合体，而class
用于封装行为和状态的抽象类型。当你用struct
来构建一个需要严格封装、拥有复杂行为和生命周期的对象时，会让人感到困惑。读者在看到struct
时，会下意识地认为它是一个简单的POD类型或数据容器，而不是一个具有复杂内部逻辑的“对象”。这可能导致对代码意图的误判，增加理解成本。// 示例：一个可能引起误解的 struct struct DatabaseConnection { // 看起来像数据，但可能内部有复杂逻辑 std::string connectionString; void connect() { /* 复杂的连接逻辑 */ } void disconnect() { /* 复杂的断开逻辑 */ } // ... 还有很多 private 成员和方法 private: Socket socket; // ... };这段代码虽然能跑，但
DatabaseConnection
这个名字和struct
关键字放在一起，会让人觉得别扭，因为数据库连接通常是需要封装复杂行为的。 -
默认
public
带来的潜在风险和冗余： 如果你用struct
来设计一个需要严格封装的OOP对象，你将不得不为所有需要保护的成员显式地加上private:
或protected:
修饰符。这不仅增加了代码量，也违背了class
默认private
的“安全至上”原则。如果你不小心忘记了，或者在后续修改中遗漏了，就可能无意中暴露了内部实现细节，破坏了封装性。而class
默认private
则提供了一个“默认安全”的起点。struct MyEncapsulatedObject { public: // 如果不写，成员默认就是 public void doSomethingPublic() { /* ... */ } private: // 必须显式写 private int internalState; void doSomethingInternal() { /* ... */ } };相比之下，使用
class
则自然得多：class MyEncapsulatedObject { private: // 默认 private，无需显式写 int internalState; void doSomethingInternal() { /* ... */ } public: void doSomethingPublic() { /* ... */ } }; 对新手或跨团队协作的挑战： 对于C++新手或者在大型团队中协作时，遵循这些约定可以降低沟通成本。如果团队中有人滥用
struct
来做复杂的OOP设计，而其他人习惯于其传统用法，就可能产生误解，甚至引发不必要的代码审查讨论。不必要的精神负担： 开发者在阅读或编写代码时，需要额外地去判断一个
struct
是否真的只是一个数据结构，还是一个伪装成struct
的class
。这种额外的思考负担，虽然微小，但在长期积累下会影响开发效率和代码清晰度。
总结来说，虽然技术上可行，但为了代码的清晰度、可读性、维护性以及与C++社区的普遍约定保持一致，强烈建议将class
用于OOP设计，而将struct
保留给那些主要用于数据聚合、行为简单且内部成员通常需要直接访问的轻量级数据结构。 这种约定能够帮助我们编写出更易于理解和维护的代码。
