📄 一句话概括
结构化解决了【读得懂】，剩下两个问题：复用和数据不被乱改——这正是 OOP 要接手的。
📝 本节和前面几节的关系
3.5~3.7 是结构化的三步，这一节说它的天花板在哪。
一、还有四件事办不到
代码复用——函数能复用，数据不能。 数据不被乱改——没有封装，谁都能改全局变量。 加功能不改老代码——要回去改判断分支。 大团队并行开发——边界只到函数，太细，挡不住互相踩。
二、复用的两个层次
函数能带走算法，但数据要重新传。 类能带走算法＋数据＋规则，基本不用改。 框架能带走骨架＋流程，只填空。 看中间一行：类凭什么比函数多带一样东西？因为类有自己的数据。
三、类凭什么比函数多带一样东西
函数没有【自己的数据】——它每次被调用都要别人把数据递进来。 类有——实例变量就是它自己的数据，跟着它一起被复制、被传递、被复用。 所以第 4 章讲类的三个功能时，第一个就是【汇总】：把该在一起的放在一起。 没有汇总，就没有后面的一切。
四、方向转向可维护与可重用
从这一节起，语言进化的目标变了： 以前是【让程序能跑】，后来是【让程序好读】，现在是【让程序好改、好复用】。 注意【好改】和【好读】不是一回事：读得懂的代码，照样可能改一处坏三处。 第 4 章开始讲 OOP 怎么做到【好改】——从三个结构开始。
五、动手 Demo：进化方向演变为重视可维护性和可重用性
结构化能做到什么、不能做到什么，列一张对照表。 再比一比三种复用单位各自能带走什么。
units = [
("函数", "算法", "数据要重新传"),
("类", "算法＋数据＋规则", "基本不用改"),
("框架", "骨架＋流程", "只填空"),
]
for name, carry, extra in units:
print(name, "能带走", carry, "｜", extra)
print("只有类带走了自己的数据")
实跑输出：
--------------------------------------------------------------------
进化方向演变为重视可维护性和可重用性
--------------------------------------------------------------------
结构化解决了【读得懂】，但还剩两个问题，**它们正是 OOP 要接手的。**
问题 结构化能给吗 为什么给不了
-------------------------------------------------------------
代码复用 部分能给 函数能复用，数据不能
数据不被乱改 不能 没有封装，谁都能改全局
加功能不改老代码 不能 要回去改判断分支
大团队并行开发 不能 边界只到函数，太细
实测【复用】这件事的两种层次：
复用单位 能带走什么 带走后还要改吗
-------------------------------------------------
函数 算法 数据要重新传
类 算法＋数据＋规则 基本不用改
框架 骨架＋流程 只填空
**看第二行**：类能把【数据和操作它的规则】一起带走——
**这是函数做不到的，因为函数没有【自己的数据】。**
所以第 4 章讲类的三个功能时，第一个就是【汇总】：**把该在一起的放在一起。**
实测这张表的关键在中间一行：只有类能带走自己的一份数据。 因为类有实例变量，函数没有——所以复用这件事，到类这一级才真正成立。
30 秒实验
- 找一个你复制过的函数，看它要带走多少参数才能复用。
- 把这些参数和逻辑合成一个类，看调用方是不是变简单了。
常见误区
- 以为函数复用等于代码复用。数据带不走，复用就不完整。
- 以为好读的代码就好改。读得懂和改得动是两件事。
自测三问（点开对答案）
1. 结构化办不到的四件事是什么？ —— 代码复用（数据带不走）、数据不被乱改、加功能不改老代码、大团队并行开发的边界。 2. 类凭什么比函数多带一样东西？ —— 因为类有实例变量——自己的数据，跟着一起被复制、传递、复用；函数每次都要别人把数据递进来。 3. 语言进化的目标变了三次，分别是什么？ —— 让程序能跑 → 让程序好读 → 让程序好改、好复用。- ☐ 下一节（3.9 没有解决全局变量问题和可重用性差的问题）
相关笔记
- 没有解决全局变量问题和可重用性差的问题 — 短板的具体数字
- 提高子程序的独立性，强化可维护性 — 复用的第一次尝试
- 以对象为中心编写软件的开发方法 — 汇总与封装
- 🧩 面向对象是怎样工作的 · 索引