面向过程代码难改因数据与行为脱钩，导致改一处引发多处错误；OOP通过封装、继承、多态将数据与行为绑定，使修改局部化。
面向过程代码为什么越写越难改
当你发现每次加一个新功能，都要在十几个函数里补参数、改全局变量、同步更新文档，基本就掉进过程式编程的典型陷阱了。它不是不能用，而是数据和行为完全脱钩，改一处，八处报错。
常见错误现象：segmentation fault 来得莫名其妙；name 变量在 cookNoodle() 里被意外覆盖，到 addSeasoning() 时已经不是原来那个值；新增一只狗的信息，得复制粘贴一整套 main() 和函数声明。
- 所有数据靠全局变量或函数参数传递，没有归属感
- 函数职责模糊——
eat_food()该打印日志？该校验狗龄？该更新饥饿值？没人管 - 想支持“猫”或“兔子”，得重写一套几乎一样的函数，而不是复用
类不是语法糖，是责任容器
class 的本质不是多写几行 {}，而是把“谁的数据”和“谁的行为”绑死。比如狗的 name、age、variety 和它的 eat()、sleep() 必须属于同一个实体，外部不能绕过规则直接操作。
使用场景：你不再写 eat_food("Tom")，而是写 tom.eat()——调用动作时，对象自己带着上下文（tom 的状态）一起过去。
- 封装不是为了“防人”，是为了让修改有边界：改
eat()内部逻辑，不影响其他狗对象 - 构造函数（如
Dog(String name, int age)）强制你在创建时就填关键信息，避免出现“名字为空的狗” - 成员变量默认
private，不是教条，是防止别人在别处偷偷改tom.age = -5
继承不是为了“省几行代码”，是为了明确 is-a 关系
别一上来就建 Animal 父类。只有当多个类型**共享同一套行为契约**，且你能清晰说出“藏獒 is a Dog”“Dog is a Animal”时，才用继承。
容易踩的坑：Dog 继承 Vehicle（因为“狗能跑”？不行）；或者为了复用 logAction() 就硬拉个父类，结果子类根本不需要这个能力。
- 优先考虑组合：比如
Dog持有HealthMonitor实例，比继承Monitorable更灵活 - Java/C# 中
protected成员看似方便子类访问，实则破坏封装边界，多数时候用public方法暴露能力更安全 - Python 的
__init__中忘记调用super().__init__()，父类字段压根没初始化，但不报错——这是静默失效
多态真正起效的地方：你根本不知道对象具体是谁
多态不是炫技，是解决“我有一堆不同动物，现在统一喂食，但每种吃法不同”的问题。关键在于：调用方只认接口，不关心实现。
示例场景：遍历 List<animal></animal>，对每个元素调用 makeSound()。你不用写 if (a instanceof Dog) {...} else if (a instanceof Cat) {...}。
- 虚函数表（vtable）机制决定了性能开销极小，别因“间接调用”怕慢
- Go 没有 class，但用接口 + 结构体方法也能实现相同效果：
func (d Dog) makeSound() { ... }，只要满足接口定义就自动多态 - JavaScript 的多态更隐蔽：只要对象有
makeSound方法，就能传给统一处理函数——但少了编译期检查，运行时TypeError: a.makeSound is not a function很常见
最常被忽略的一点：OOP 不是让代码变短，是让变化局部化。一个需求变更只影响一个类，而不是散落在 17 个函数里——这点在接手别人代码时，感受最深。
