波仔
🧩 第二章 似是而非：面向对象与现实世界
📄 一句话概括

既然不对齐，为什么还用现实的词命名？因为可读性——业务词命名让不懂代码的人也能参与讨论。

📝 本节和前面几节的关系

2.8 说类与现实不对齐，这一节说相似仍然有价值——这是本章的收束。

一、可读性是可以量的

实测：把类名拆成单词，数一数落在业务词上有几个。 业务词命名那组：7 个业务词、0 个技术词。 技术词命名那组：3 个业务词、8 个技术词——业务词被盖住了。 光看名字就知道系统在做什么生意——这就是相似带来的东西。

二、共同语言

产品经理能看懂 Order.cancel()，看不懂 StateMachine.transition(3)。 这一条的价值被严重低估了：它决定了业务方能不能参与技术讨论。 命名一旦全变成技术词，需求评审就变成翻译会——翻译过程一定会丢信息。

三、相似的正确用法

该像的地方：核心业务概念——客户、订单、账单、库存。用行业里的叫法。 不必像的地方：技术构件——仓储、网关、事件总线。这些没有行业叫法，用了反而绕。 判断标准：这个词业务方会不会说？会说就用它，不会说就用技术词。

四、本章收束

这一章走了一条完整的路：先教怎么用比喻（2.1），再拆穿比喻（2.5、2.6）， 最后给出不依赖比喻的定义（2.7），并说清它与现实的真实关系（2.8、2.9）。 结论一句话：像，但不是；像有好处，但不能当依据。 第 3 章换个角度，从语言史看这些概念是怎么长出来的。

五、动手 Demo：与现实世界的相似增大了可能性

两组类名，一组用业务词、一组用技术词，各拆成单词统计。 看可读性这件事能不能量化。

import re
DOMAIN = {"Customer", "Order", "Item", "Product", "Payment", "Address"}
TECH = {"Repository", "Gateway", "Service", "Mapper",
        "Base", "Session", "Entity", "Data"}

def words(name):
    return re.findall(r"[A-Z][a-z]*", name)

def score(group):
    ws = [w for n in group for w in words(n)]
    return (sum(1 for w in ws if w in DOMAIN),
            sum(1 for w in ws if w in TECH))

dom = ["Customer", "Order", "OrderItem", "Product", "Payment", "Address"]
tech = ["Session", "OrderRepository", "PaymentGateway",
        "OrderService", "DataMapper", "BaseEntity"]
print("业务词命名", score(dom))
print("技术词命名", score(tech))

实跑输出：

--------------------------------------------------------------------
与现实世界的相似增大了可能性
--------------------------------------------------------------------

  既然不对齐，为什么还要用现实里的词命名？**因为可读性。**
  实测：**把类名拆成单词，看多少落在业务词上。**

  命名风格                 业务词     技术词
  -------------------------------------------
  业务词命名（6 个类）     7          0
  技术词命名（6 个类）     3          8

  实测：业务词命名那组拆出 **7 个业务词、0 个技术词**；
  技术词命名那组是 **3 个业务词、8 个技术词**——正好反过来。

  **业务词命名的类，光看名字就知道系统在做什么生意。**
  技术词命名的类，光看名字只知道它怎么实现——**换个业务照样能用。**

  这就是 2.9 说的【相似增大了可能性】：
  **用现实里的词命名，让不懂代码的人也能参与讨论。**
  产品经理能看懂 `Order.cancel()`，看不懂 `StateMachine.transition(3)`。
  **这一条实实在在的价值，是它让开发者和业务方有了共同语言。**

实测：业务词命名 7 业务／0 技术；技术词命名 3 业务／8 技术。 可读性不是感觉，是能数的——业务词多，光看名字就知道系统在做什么。

30 秒实验

  1. 把你的类名分成【业务概念】和【技术构件】两堆，看比例是否合理。
  2. 找一个技术词命名的业务类，试着换成行业里的叫法。

常见误区

  1. 以为不与现实对齐就不该用现实的词。命名和建模是两件事。
  2. 把所有类都改成技术词。业务方会看不懂，评审要靠翻译。
自测三问（点开对答案） 1. 为什么还用现实的词命名？ —— 为了可读性和共同语言：业务词命名的类，光看名字就知道系统在做什么生意。 2. 哪些该像、哪些不必像？ —— 核心业务概念（客户、订单、账单）用行业叫法；技术构件（仓储、网关）直接用技术词。 3. 本章的结论是什么？ —— 像，但不是；像有好处（可读性、共同语言），但不能当依据。

相关笔记