📄 一句话概括
分开想的具体做法：同一句话问两遍——代码里能验证吗？组织里能验证吗？实测六个说法里只有 4 个两边都成立，这一半才是能搬走的。
📝 本节和前面几节的关系
7.4 找出了混乱，这一节给办法：不争哪个含义对，而是把一句话拆成两问。
一、拆成两问
对任何一个说法，问：代码里能验证吗？组织里能验证吗？ 两问的答案可以不同——不同才是信息，不是矛盾。 这种做法不要求你选边：两边都留，各自去各自的场合用。
二、实测：六个说法的两问结果
两边都能验证的 4 个：这个类只做一件事、继承链符合【是一种】、接口够窄、职责分配合理。 只在代码侧能验证的 2 个：这段代码没有重复、这个变量名取得好。 只在组织侧能验证的 0 个——这是个有意思的结果：这份样本里没有【组织能验、代码验不了】的说法。 为什么：因为组织侧的约束一旦说清，基本都能落成代码里的结构；反过来则不然。
三、哪一半能搬走
两边都成立的 4 个 = 通用部分，可以搬到需求、设计、甚至组织管理上。 【代码没有重复】【变量名取得好】只在代码侧成立，换成组织就没有对应物——搬不走。 所以分开想的好处是：你知道哪一半能搬。 搬错地方的那些理论，都是从这来的。
四、用法的三条注意
先问再答：别急着说【这不面向对象】，先问是哪个含义。 两问都要答：只答一半，就等于默认另一半不成立。 答【不能】不丢人：组织里没有对应物，说明这条是纯技术规矩，它一样重要。
五、动手 Demo：分为编程技术和归纳整理法进行思考
六个常见说法，逐个过两问：代码里能验证吗、组织里能验证吗。 最后数一数两边都成立的有几个——那就是【通用】的那部分。
probe = [
("这个类只做一件事", True, True),
("这条继承链符合【是一种】", True, True),
("这个接口够窄", True, True),
("这段代码没有重复", True, False),
("职责分配合理", True, True),
("这个变量名取得好", True, False),
]
ok_org = sum(1 for s, c, o in probe if o)
both = sum(1 for s, c, o in probe if c and o)
print(ok_org, both) # 4 4
实跑输出：
--------------------------------------------------------------------
分为编程技术和归纳整理法进行思考
--------------------------------------------------------------------
分开之后，**同一句话要问两遍：代码里能验证吗？组织里能验证吗？**实测六个说法：
说法 代码里能验证 组织里能验证
-----------------------------------------------------------
这个类只做一件事 能 能
这条继承链符合【是一种】 能 能
这个接口够窄 能 能
这段代码没有重复 能 不能
职责分配合理 能 能
这个变量名取得好 能 不能
六个说法里，代码侧能验证 6 个
组织侧能验证 4 个
两边都能 4 个
**实测：两边都成立的有 4 个——这就是【通用】的部分。**
**而【代码里没有重复】【变量名取得好】只在代码侧成立**——换成组织就没有对应物。
**所以分开想的好处是：你知道哪一半能搬走，哪一半搬不走。**
实测：代码侧能验证 6 个、组织侧 4 个、两边都能 4 个。 组织侧没有【独有】的说法——这点值得记住：组织约束说清了，基本都能落成代码结构。 而【没有重复】【变量名好】搬不到组织去，这就是分开想的实际收获。
30 秒实验
- 挑三条你信奉的设计原则，各过一遍两问，标出哪条只在代码侧成立。
- 找一条【只在组织侧成立】的说法出来（这份样本里是 0 个，试着打破它）。
常见误区
- 以为两问答案不同就是矛盾。不同恰恰是信息。
- 以为只在代码侧成立的规矩就不重要。纯技术规矩一样是规矩。
自测三问（点开对答案）
1. 分开想的具体动作是什么？ —— 对同一个说法连问两遍：代码里能验证吗、组织里能验证吗，两问分开答。 2. 实测六个说法怎么分布？ —— 代码侧 6 个、组织侧 4 个、两边都能 4 个、组织侧独有 0 个。 3. 哪一半能搬走？ —— 两边都成立的 4 个才是通用部分；只在代码侧成立的搬不走。- ☐ 7.6 为何化为了通用的归纳整理法
相关笔记
- 两种含义引起混乱 — 这一节要解决的问题
- 原因之三：面向对象的概念是抽象的 — 为什么概念容易混
- 为何化为了通用的归纳整理法 — 为什么它能通用
- 🧩 面向对象是怎样工作的 · 索引