📄 一句话概括
设计不只是分 Class——实测 10 件设计事项里，只有 5 件与代码结构有关，另外 5 件（日志、配置、测试、部署）同样在设计范围内。
📝 本节和前面几节的关系
第九章把【记什么】定完了，这一章讲怎么把它做成好维护的结构。先划清设计的范围。
一、很多人把设计等同于分 Class
一提设计就想到【有几个类、谁继承谁】——这只是一半。 实测一份设计清单，10 件事里有 5 件与代码结构直接相关：类的划分、包的划分、接口的形状、数据放在哪、异常的边界。 另外 5 件与结构无关但同样重要：命名与编码规范、日志与监控、配置与环境、测试策略、部署与发布。
二、为什么这些也算设计
它们决定了后期能不能改——结构再好，没有日志就查不出问题。 它们也决定了别人能不能接手：命名规范不统一，读代码比读需求还慢。 所以设计不是【画完类图就结束】，它是【让这套东西在一年后还能动】的全部安排。
三、本章只讲结构那一半
因为结构那一半最依赖【面向对象的思路】——本章的 10.3~10.7 全是结构。 另一半靠经验积累：日志打什么、配置放哪、测试覆盖到哪，没有通用公式。 但不知道另一半存在，就会以为设计做完了——这是新手最常见的高估。
四、这一章的走向
10.2 讲清一个转向：效率让位给可维护性与可重用性。 10.3~10.6 三个设计目标：去重复、提独立性、避免循环依赖。 10.7~10.8 收口到本章的主旨：拟人化和职责分配。 COLUMN 讲 JS 那种【执行时不受类约束】的语言。
五、动手 Demo：设计的目标范围很广
列一份设计要管的事项清单，标出哪些与代码结构直接相关。 数一数两边的比例。
items = [("类的划分", "结构"), ("包的划分", "结构"),
("接口的形状", "结构"), ("数据放在哪", "结构"),
("异常的边界", "结构"), ("命名与编码规范", "非结构"),
("日志与监控", "非结构"), ("配置与环境", "非结构"),
("测试策略", "非结构"), ("部署与发布", "非结构")]
st = sum(1 for a, b in items if b == "结构")
print(len(items), st, len(items) - st) # 10 5 5
实跑输出：
--------------------------------------------------------------------
设计的目标范围很广
--------------------------------------------------------------------
一提到设计，很多人只想到【类怎么分】。实测一份设计清单：
设计要管的事 属于
--------------------------
类的划分 结构
包的划分 结构
接口的形状 结构
数据放在哪 结构
异常的边界 结构
命名与编码规范 非结构
日志与监控 非结构
配置与环境 非结构
测试策略 非结构
部署与发布 非结构
设计要管的事 10 件
与代码结构直接相关 5 件
与结构无关但同样重要 5 件
**实测一半对一半**——设计不只是分Class，**日志、配置、测试、部署都在设计范围内。**
**但本章只讲结构那一半**，因为它最依赖【面向对象的思路】。
**另一半靠经验积累**，没有通用公式。
实测：10 件设计事项里 5 件是结构、5 件不是——正好一半对一半。 日志、配置、测试、部署都在设计范围内，只是不靠类图表达。 本章只讲结构那一半，另一半靠经验。
30 秒实验
- 把你的项目按这 10 件事逐项打分，看哪几件其实没人管。
- 挑一件非结构的事（比如日志），写下你们现在的约定。
常见误区
- 以为设计就是画类图。那只占一半。
- 以为非结构的事不用设计。它们决定一年后还能不能改。
自测三问（点开对答案）
1. 设计范围包含哪两类事？ —— 与代码结构直接相关的（类、包、接口、数据、异常）和不直接相关的（命名、日志、配置、测试、部署）。 2. 实测比例如何？ —— 10 件事里 5 件结构、5 件非结构。 3. 为什么本章只讲结构？ —— 结构最依赖面向对象思路；另一半靠经验，没有通用公式。- ☐ 10.2 相比运行效率，现在更重视可维护性和可重用性
相关笔记
- 建模蕴含着软件开发的乐趣 — 上一章的收口
- 设计目标之一：去除重复 — 第一个目标
- 决心决定OOP的生死 — 结构投入的决心
- 🧩 面向对象是怎样工作的 · 索引