波仔
💻 第十二章 SE负责监管计算机系统的构建
📄 一句话概括

系统交付只是开始，维护才是长跑——面向对象的封装与复用把【改一处、牵全身】收敛成【改一处、自动生效】，维护成本大幅下降。

📝 本节和前面几节的关系

拆解把系统建起来，本节看面向对象怎么让系统【养起来便宜】——这是第七章伏笔在工程层的兑现。

一、维护是系统的常态而非例外

系统上线后，税率变、规则改、接口换——需求永远在动； 维护成本占系统全生命周期成本的大头——写得快不如改得动； 【改一处、牵全身】是维护的最大噩梦：复制粘贴式代码一处改动要追着改 N 处。

二、面向对象怎么救场

封装：公共逻辑（如税率计算）只写在一个类里，调用方只见接口不见实现； 复用：五个模块共用同一个 TaxCalculator——规则一改，只动这一个类； 继承与多态：新需求派生子类扩展，老代码一行不动——【对扩展开放、对修改关闭】； 回看 7.9 的三大特性：当时学的是语法，此刻看到的是维护阶段的回报。

三、工程层的印证

现代系统普遍按面向对象／组件化组织——不是审美偏好，是维护经济学； 本章 12.5 的拆解给【块】，面向对象给【块的封装与拼装规则】——两者是一套工程方法的两半； 【⚠️ 2026 现状】微服务把【改一处、自动生效】推到系统之间：服务独立部署，改一个服务不用动全系统——思想仍是这一条。

四、动手 Demo：改税率：两种写法的账

同一个小改动【税率 5% 改 8%】，对比复制粘贴式与面向对象式的改动点数量。

modules = ["销售", "库存", "报表", "工资", "发票"]
copy_style = len(modules)   # 每个模块各抄一份税率计算
oo_style = 1                # 只有 TaxCalculator 一处
print("复制粘贴式改动:", copy_style, "处")
print("面向对象式改动:", oo_style, "处")

实跑输出：

--------------------------------------------------------------------
面向对象法简化了系统维护工作
--------------------------------------------------------------------

维护的痛: 需求一改, 到处开花。看看【税率从 5% 改成 8%】这个小改动
在两种写法下的工作量:

    [复制粘贴式] 税率计算抄在 5 个模块里, 改动 = 5 处:
        销售模块 -> 改一处
        库存模块 -> 改一处
        报表模块 -> 改一处
        工资模块 -> 改一处
        发票模块 -> 改一处

    [面向对象式] 税率计算只写在 TaxCalculator 一个类里, 5 个模块都调用它:
        TaxCalculator -> 改一处
        其余 5 个模块 -> 一行都不用动

  写法           改动点     漏改风险
  -----------------------------------------------------
  复制粘贴式     5 处       五处漏一处就出账目事故
  面向对象式     1 处       改基类, 调用方全部自动生效

封装 + 复用 = 改动收敛到一处——这正是 7.9【三大特性】在维护阶段的回报。

5 处对 1 处——更危险的不是工作量，而是复制粘贴式【漏改一处就是账目事故】。 把模块数换成 50 想想大系统：维护差距是数量级的。

30 秒实验

  1. 在自己写过的代码里找一处【复制了三遍的逻辑】，设想用面向对象收拢它。
  2. 用【对扩展开放、对修改关闭】解释为什么继承让新需求不动老代码。

常见误区

  1. 以为面向对象是让程序【写得优雅】——真正的回报在维护成本，不在初次编写。
  2. 以为封装只是把代码塞进类——封装的要害是【只暴露接口、藏起实现】，改动才有收敛点。
自测三问（点开对答案） 1. 维护为什么是大头成本？ —— 需求永远在动，改动的频次与代价远超初次开发。 2. 面向对象省维护的机制？ —— 封装收敛改动点＋复用统一公共逻辑＋继承扩展不动老码。 3. 【改一处、自动生效】依赖什么前提？ —— 公共逻辑只存在一份，调用方全部走接口。

相关笔记