一、技术讲完，剩人的事

同样的技术，用得成不成，看决心。 书里这句话容易被当成励志，其实它是工程判断：OOP 的成本在【现在】，收益在【以后】。 而人天生对【以后的收益】打折。

二、两张对照

需求：三种形状算面积，未来还要加两种。 过程式：3 个函数各带 1 条 if 链；加 2 种形状＝每个函数加 2 条分支；改动落在已有函数内部；回归范围是整个函数。 OOP：3 个类；加 2 种形状＝加 2 个类；改动落在新文件；回归范围是新增部分。 差别不在【写多少】，在【改哪里】。

三、量一量上下文

实测一个更硬的指标：改动的上下文有多大。 过程式改 area_proc，要读懂整条 if 链（3 种 × 每条 2 行＝6 行）；OOP 加一个类，只要读懂 Rect 这一个类（5 行）。 看着差不多——但形状涨到 20 种时，前者变 40 行，后者还是 5 行。 差距不在今天，在明年。

四、决心的确切含义

不是学不会，是肯不肯在【现在就多写一个类】。 短期看是负担，长期看是唯一能撑住规模的做法。 所以这一节不是劝人向善，是把账摊开：你现在省下的那一个类，将来会以 30 倍的阅读量还回来。 这也解释了为什么很多团队【知道 OOP 却不用】——不是不懂，是没算过这笔账。

五、动手 Demo：决心决定 OOP 的生死

同需求两种写法的对照表。 再量一量：改一处时，要读懂多少行上下文。

kinds_now, kinds_future = 3, 20
proc_per_kind = 2      # if 链里每种形状 2 行
oop_per_class = 5      # 一个类 5 行
print("现在：过程式", kinds_now * proc_per_kind, "行 vs OOP", oop_per_class, "行")
print("将来：过程式", kinds_future * proc_per_kind, "行 vs OOP", oop_per_class, "行")

实跑输出：

--------------------------------------------------------------------
决心决定 OOP 的生死
--------------------------------------------------------------------

  最后一节说的是人的事：**同样的技术，用得成不成，看决心。**
  但决心也可以量——**看两种写法在同一需求下的差距有多大。**

  需求：三种形状算面积，未来还要加两种。

                       过程式                    OOP
  ---------------------------------------------------------
  现在要写             3 个函数 × 1 条 if 链     3 个类
  加 2 种形状          每函数加 2 条分支         加 2 个类
  改动落在哪           已有函数内部              新文件
  要回归测试的范围     整个函数                  新增部分

  实测一个更硬的指标：**改动的【上下文】有多大。**

      过程式：改 area_proc 时，要读懂整条 if 链（现有 3 种 × 每条 2 行）
      OOP：   加一个类时，只要读懂 Rect 这一个类（5 行）

  **要读懂的代码量，从 6 行降到 5 行——看着差不多；**
  **但形状涨到 20 种时，前者变 40 行，后者还是 5 行。**

  **这就是【决心】的意思：不是学不会，是肯不肯在【现在就多写一个类】。**
  **短期看是负担，长期看是唯一能撑住规模的做法。**

实测：现在 6 行 vs 5 行，看着差不多；形状涨到 20 种就是 40 行 vs 5 行。 决心不是态度，是算账：现在省下的那个类，将来以几十倍的阅读量还回来。

30 秒实验

1. 给你的项目算一算：最常改的那个函数，改一次要读懂多少行。
2. 找一个【知道该抽类却没抽】的地方，估一下它现在的 if 链有多长。

常见误区

1. 以为这一节是励志。它是把成本摊开算给你看。
2. 以为 OOP 一定比过程式好。一次性脚本用 OOP 是负担。

• ☐ 下一节（COLUMN 当今的OOP 从网页工具进化而来的PHP）

相关笔记

• 对进化的 OOP结构的总结 — 本章技术的收口
• 面向对象难的原因 — 难在人这一侧
• 当今的OOP 从网页工具进化而来的PHP — 换个视角看这门技术的进化
• 🧩 面向对象是怎样工作的 · 索引