波仔
💻 第七章 成为会使用面向对象编程的程序员吧
📄 一句话概括

观点 3：OOP 是为大型程序而生的开发方法——类是天然的分工单元，拆得动、分得下、接得上。

📝 本节和前面几节的关系

小程序怎么写都快；规模一上十万行，组织方式就成了生死线——本节看 OOP 的大场面能力。

一、规模爆炸带来的分工问题

百万行的程序不可能一个人写，必须拆模块、分组并行、最后组装。 拆不开就是灾难：改一个全局变量要在百万行里搜一遍；两个人同时改一个函数必然打架。 第三章那种【一个文件从头写到尾】的手工汇编式开发，到这个规模就彻底失灵。

二、类是天然的分工单元

每个类职责单一、接口清晰——小组认领几个类各自开工，互不踩脚。 组间只对接口说话：一组给二组的方法签名定了，两边就能并行——你写你的实现，我写我的调用。 7.3 的拼装观在团队尺度重演：零件能分开造，靠的还是插座规格。

三、接得上：接口即合同

各组完工后按接口拼装验收——接口就是小组之间的合同，签了就要守。 合同先行还有个好处：测试可以提前写——对着一纸接口就能造测试桩，不必等实现完工。 【⚠️ 2026 现状】微服务架构把【拆类分工】再放大到【拆服务分工】：每个服务就是一个被网络接口包裹的巨型类。

四、动手 Demo：大型程序拆类分工

模拟一个 2 万行的图书管理系统：拆 8 个类、3 个小组并行，最后按接口拼装。

mods = [
    ("Book", 2000), ("User", 1800), ("Loan", 2600),
    ("DB", 3200),   ("UI", 3600),   ("Search", 2400),
    ("Report", 2200), ("Main", 2200),
]
total = sum(loc for _, loc in mods)
for name, loc in mods:
    print(name, loc)
print("total", total)

实跑输出：

--------------------------------------------------------------------
观点 3——适用于大型程序的开发方法
--------------------------------------------------------------------

小程序一个人写; 百万行的系统必须拆类分工。模拟一个
【图书管理系统】(约 2 万行) 拆成 8 个类、3 个小组并行:

  模块          负责小组     职责         约行数
  -----------------------------------------------
  Book 类       一组         书记录       2000
  User 类       一组         读者记录     1800
  Loan 类       一组         借还规则     2600
  DB 类         二组         存取数据     3200
  UI 类         二组         界面显示     3600
  Search 类     三组         检索         2400
  Report 类     三组         统计报表     2200
  Main 类       三组         组装入口     2200

    合计: 20000 行, 3 个小组同时开工, 最后按接口拼装验收

类是天然的分工单元: 职责单一、接口清晰, 组间只对接口说话。
【⚠️ 2026 现状】今天的微服务架构, 就是把【拆类分工】再放大到【拆服务分工】。

8 个类 3 个组，谁也不必等谁全部完工——分工单元越小越清晰，并行度越高。 把表格里的类换成微服务、小组换成团队，就是 2026 年大型系统的分工图——思想一脉相承。

30 秒实验

  1. 把一个想象中的【外卖点单系统】拆成 6 个类，标出哪几个可以并行开发。
  2. 写两个只有方法签名没有实现的【接口桩】，体会合同先行的感觉。

常见误区

  1. 以为大程序只是小程序的加长版——规模跨过临界点，组织方式本身决定成败。
  2. 以为分工就是把人分开——没有清晰的接口合同，分开只会更快地打架。
自测三问（点开对答案） 1. 为什么说类是天然的分工单元？ —— 职责单一、接口清晰，小组可认领后并行开发。 2. 接口在团队协作中扮演什么角色？ —— 小组之间的合同——签名定了就能并行与提前测试。 3. 2026 年的微服务与观点 3 什么关系？ —— 微服务把拆类分工放大到拆服务分工，思想同源。

相关笔记