1. 抽象不是"设计"出来的，是"用"出来的
作为一个写了十多年 Python 的人，我被问过最多的问题之一就是："你是怎么想到要这样抽象的？"问这话的人，往往刚学完 OOP，看了一堆设计模式的书，发现书上那些类图画得明明白白，但一回到自己的项目里就蒙了——我的业务到底该抽哪些类？接口该怎么定才"标准"？
我对这个问题的答案，可能跟很多人想的不一样：你根本不需要"想到"要抽象，你只需要先用起来，用着用着，抽象自己就会浮现出来。
所谓的"抽象源于使用经验"，说得更直白一点就是：你还没用过三只不同的支付渠道之前，是设计不出一个好的支付接口的。你还没搬过三次家之前，是规划不出一个真正好用的收纳系统的。这不是谦虚，而是因为抽象的本质是归纳，不是演绎——你得先有足够的样本，才归纳得出共性。
1.1 先反驳一个流行认知：抽象不是"画"出来的
市面上很多教材给学生传递了一种错觉：写代码之前，先画类图、先定义接口、先设计好继承体系，然后照着图填代码，这就是"面向对象设计"。我见过太多初学 OOP 的同事栽在这上面，项目还没写几行，先搞了一个三层继承的结构，急着把"各种可能的变化"全预判进去，结果半年后被迫全部推翻。
为什么前瞻式设计在抽象这件事上特别不靠谱？原因很简单：**你还没用过具体实现，就不知道该抽什么。**比如你只写过银行转账这一种支付方式，你脑子里的"支付接口"大概长这样：
def pay(money): # 调银行接口但等你写了第二个——微信支付的二维码拉起——你才会发现，原来"支付"这个动作在不同渠道里差距巨大，微信的回调是异步的，银行可能是同步的。等你写了第三种，你可能才会意识到"支付方式"这件事，真正稳定的部分其实是：订单状态流转和回调通知，而不是支付那头。
这个过程就叫"使用经验"。你把三种渠道都实现一遍，你会清晰地看到：哪一部分代码是复制粘贴改改字段的，哪一部分是每次重写逻辑的。复制粘贴的三次，说明这是共性；每次重写的那块，说明这是差异。抽象，不过是把"复制粘贴了三遍"的东西提取出来而已。
1.2 抽象本质上是"找共性、隔变化"，共性依赖样本量
我可以给你一个非常朴素的观察方式：下次你在写代码的时候，发现自己又一次按下Ctrl + C、Ctrl + V，先别急着骂自己，反而可以停下来想一想——这已经是第几次粘贴了？
第一次出现重复代码，是正常的，不抽象，先忍着。第二次出现相似逻辑，你也先忍着，但开始在脑子里给这片区域打标记。第三次出现同一结构的时候，你就有了足够的信息量——这时候你再动手抽象，往往能一次抽中。
为什么非要等到第三次？很多人不耐烦，觉得第二次就可以抽了。我的经验是：第二份重复代码往往只是"看起来相似"的陷阱，两个需求可能只在字段级别一样，行为上其实已经分化了。没有第三个样本，你根本判断不了哪部分是真正的共性，哪部分是偶然的相似。举一个很典型的例子，两个函数都有一段"算价格"的逻辑，但一个要算折扣、一个要算阶梯价，如果你在第二次出现时就抽了个"统一的价格计算方法"，结果就是函数里塞了一堆 if 分支，反而把差异给搅混了。等到第三个样本出现，你一眼就能看出：折扣、阶梯价、会员价，其实他们共享的是"基于原价做变换"这个骨架，具体变换规则才是变化的。这样抽出来的接口，才会稳。
1.3 "使用经验"不只是用得多，还包括被用得难受
抽象还有一个很隐蔽的来源：调用方的吐槽。很多好接口不是定义者设计出来的，是被使用者"逼"出来的。
我以前维护过一个内部组件，最初结构是数据类加一堆游离的函数，调用方每次都要按特定顺序调用四个函数才能拿结果，结果一个季度内被三个团队同时投诉"太容易漏步骤"。后来我把四个函数收敛成一个上下文管理器，让调用方只需写三行。这个设计改动，不是我坐在那冥想出来的，是使用者的痛苦反推出来的。
所以如果你问我"怎么培养抽象能力"，我的建议是：少看设计模式书，多去"被使用"。你把模块发出去，让别人调用，然后认真听他们的抱怨——抱怨"这个字段为什么必须传"、抱怨"为什么有两个函数名这么像"——所有抱怨里都藏着抽象的信号。因为这些抱怨背后都有一个共性问题：**调用方对模块的预期，跟模块暴露的形态不一致。**而抽象的目标，恰恰就是让接口形态贴合大部分调用方的预期。
2. 使用中的三个信号：该动手抽象了
说清楚"抽象为什么要等使用经验"之后，下一个自然的问题就是：**那使用经验积累到什么程度，才算到了该动手的时机呢？**这里我总结了三个观察点，来自这些年实战里踩过的坑。你写代码时碰到任何一个，就意味着该停下复制粘贴的手，认真考虑抽象了。
信号一：同一段逻辑出现了第二次，你开始想复制粘贴。
严格来说，第一次出现写得有点复杂的代码，是正常的。第二次出现"跟上次差不多的代码"，就要警惕了。第三次出现，基本可以确定是抽象的红线。
为什么是三条线的标准？因为这一次次的重复，实际上是在给你提供判断依据：你看第一次和第二次的差异，如果差异集中在几个字段赋值，那说明共性是流程框架，后续抽象统一流程即可；如果差异涉及判断分支、算法逻辑都不一样了，那说明现在的重复只是表面现象，真正的共性和差异还没分清楚，还需要再等一等。复制粘贴得越多，你对"这段代码里到底什么在变"就越清楚。
信号二：业务里出现了清晰可感的"变化点"。
这个信号比复制粘贴更值得留意。所谓"变化点"，是指你的业务过程中出现了一个位置，大部分流程都是一样的，只有其中一小段在不同场景下有不同表现。最常见的例子就是数据源切换：同一个报表功能，今天连 MySQL，明天连 Oracle，后天要支持文件导入。筛选、计算、格式化的逻辑全一样，就是"读数据"这一步在变。再比如日志输出：本地开发的时候往终端打，测试环境打到文件，线上要采集到日志中心——其他都一样，只有"日志去向"这一截在变。
这种变化点的存在，早期靠 if 分支还能勉强支撑，加一两个场景还好，加到第五个场景，代码里面全是"如果走这个数据源、否则走那个数据源"的分流，根本没法维护。抽象在这时候的作用，就是把这一个变化点封装到接口后面，让调用方完全无感。
信号三：数据和操作开始"绑定在一起"了。
第三个信号比较微妙，但极常见：你的代码里开始频繁出现一些数据字典、数据列表，被若干个不同的函数转来转去，每个函数都对它做一小步操作。比如：
user = { "name": "张三", "email": "zhangsan@example.com", "level": 3, } def send_welcome_email(user): ... def update_level(user, new_level): ... def check_permission(user, action): ...这三个函数都以 user 字典作为入参，彼此之间没有任何约束，谁都可以在任何地方塞一个缺字段的字典进来。运行时报错了，你还要一层层追查是哪个调用方漏了字段。这种"数据裸奔 + 一堆围绕它的函数"的形态，实际上就是在告诉你：**这块数据应该有自己的管家了。**把它收进一个类，把相关操作变成这个类的方法，数据和行为从此绑定，外部再也无法绕过约束去操作它。
我把这三个信号整理成一个简单的自检表，方便你写代码的时候对照：
| 信号 | 观察点 | 应对时机 | 抽象动作 |
|---|---|---|---|
| 重复复制 | 同一函数或逻辑出现在两处以上 | 出现第三次时 | 提取公共函数或基类方法 |
| 变化点 | 流程相同、中间一小段在变 | 出现了两种不同分支 | 把变化段封装为接口/策略 |
| 数据裸奔 | 结构被多个函数转手、无归属 | 出错定位困难时 | 收进类，附带行为，约束入口 |
注意，这三个信号有时候是叠加出现的。一个模块连续出现两个信号，你基本可以确定这块确实该动手了。
3. 订单系统演化实录：从写死到分层只用了三步
光说信号可能还是有点抽象，我用一个非常常见的业务场景——订单系统——完整走一遍"从具体到抽象"的过程。这是我在实际项目里总结出来的通用三步演化法，你可以直接拿去套用。
3.1 阶段一：先把它写死，老老实实一个函数搞定
假设你的产品一开始只有一种订单：普通商品订单。最朴素、最直接的写法长这样：
def create_order(user_id, product_id, quantity): # 1. 校验商品状态 product = get_product(product_id) if not product.is_available(): raise ProductNotAvailableError(product_id) # 2. 算价格 price = product.price * quantity # 3. 扣库存 reduce_stock(product_id, quantity) # 4. 生成订单记录 order_id = uuid4().hex save_order(user_id, product_id, quantity, price, order_id) # 5. 发通知 notify_user(user_id, f"您的订单 {order_id} 已创建") return order_id我知道有些同学看到这里会本能地想："这个函数太长、职责不单一，要不要拆？"我的答案是：**不着急。**你手里只有一个订单类型，你不知道这个业务未来会往哪个方向演化，这时候强行拆成五个小函数，只会让你的代码凭空多出五个还不确定边界的抽象。先跑起来，先让业务验证，这是企业里做真实项目的节奏。
3.2 阶段二：第二个相似需求出现，先拆"共用部分"和"差异部分"
很快，产品经理来了，说会员下单时，要按会员等级打折。这时候你有了第二个订单类型：会员订单。仔细看一眼，它跟普通订单相比，90% 的逻辑都一样，只有"算价格"这一步不同——要按会员折扣计算。
这时候你已经有第一次和第二次的样本了，可以开始做第一次抽象。但请注意，这一步的抽象粒度很关键：只提取雷打不动的公共部分，差异部分坚决不强行统一。
def _validate_product(product_id, quantity): product = get_product(product_id) if not product.is_available(): raise ProductNotAvailableError(product_id) return product def _reduce_stock(product_id, quantity): reduce_stock(product_id, quantity) def _create_order_record(user_id, product, quantity, price): order_id = uuid4().hex save_order(user_id, product.id, quantity, price, order_id) return order_id def _notify(user_id, order_id): notify_user(user_id, f"您的订单 {order_id} 已创建")然后两个具体的订单函数各自调用这些公共函数，只留下"算价格"这一段各自实现：
def create_normal_order(user_id, product_id, quantity): product = _validate_product(product_id, quantity) price = product.price * quantity _reduce_stock(product_id, quantity) order_id = _create_order_record(user_id, product, quantity, price) _notify(user_id, order_id) return order_id def create_member_order(user_id, product_id, quantity, member_level): product = _validate_product(product_id, quantity) price = product.price * quantity * member_discount(member_level) _reduce_stock(product_id, quantity) order_id = _create_order_record(user_id, product, quantity, price) _notify(user_id, order_id) return order_id这一步做完了，代码里不再有重复，两个新函数都变短了。这就是"第二次使用"阶段该有的动作。有些学习者会问：为什么不直接在第一次就写全套类结构？还是那句话，第一个版本的时候你连第二个订单类型的面貌都不知道，设计的类容易出现"自以为抽象、实则抽象错方向"的问题。
3.3 阶段三：第三个样本出现，才谈类和多态
时间又过了两个迭代，团队要上"团购订单"——多人下单、价格是阶梯价。团购订单跟前面两个的区别更大一些，计算规则的差别越来越多，三个函数虽然共用了公共小函数，但"验证、计价、扣库存、生成订单、通知"这个整体流程在三个函数里反复出现，代码的骨架重复率已经很高了。
这时候才到了引入"类 + 多态"的时机。为什么是现在？因为你自己已经有了三个关于"订单怎么创建"的真实样例，你可以回头看它们，发现共性是那五步流程，差异都集中在calc_price、validate等少数行为上。差异点你已经摸清了，抽象成基类才会命中靶心：
from abc import ABC, abstractmethod class OrderCreator(ABC): def __init__(self, user_id, product_id, quantity): self.user_id = user_id self.product_id = product_id self.quantity = quantity def validate(self) -> None: product = get_product(self.product_id) if not product.is_available(): raise ProductNotAvailableError(self.product_id) self.product = product @abstractmethod def calc_price(self) -> float: """不同订单类型各自实现计价逻辑""" def create(self): self.validate() price = self.calc_price() reduce_stock(self.product_id, self.quantity) order_id = uuid4().hex save_order(self.user_id, self.product.id, self.quantity, price, order_id) notify_user(self.user_id, f"您的订单 {order_id} 已创建") return order_id class NormalOrderCreator(OrderCreator): def calc_price(self) -> float: return self.product.price * self.quantity class MemberOrderCreator(OrderCreator): def __init__(self, user_id, product_id, quantity, member_level): super().__init__(user_id, product_id, quantity) self.member_level = member_level def calc_price(self) -> float: return self.product.price * self.quantity * member_discount(self.member_level) class GroupOrderCreator(OrderCreator): def __init__(self, user_id, product_id, quantity, group_size): super().__init__(user_id, product_id, quantity) self.group_size = group_size def validate(self) -> None: super().validate() if self.quantity < self.group_size: raise GroupOrderTooSmallError() def calc_price(self) -> float: return self.product.price * self.quantity * group_discount(self.quantity)调用方统一走create()，外部代码对每个子类的差异是彻底无感的。到了这一步，你真正获得了 OOP 抽象的好处：新增第四种订单时（比如预售订单），只需要继承OrderCreator、实现自己的calc_price，主流程一动不用动。这个"加一个子类就能扩展"的能力，恰恰是前面两个阶段积累使用经验换来的。
3.4 这个演化过程揭示的抽象节奏
复盘上面三步，你会发现一个规律：**抽象是分层的，不是一次到位的。**第一次抽象只收敛了公共函数，第二次抽象才收敛到类结构。而且每一次抽象时机的出现，都对应一个真实的业务需求落地，而不是架构师坐在那里的脑补。
很多人一上来就把第三步做完，导致的问题是：你根本没有三个真实案例作为依据，抽象基类的方法签名很容易定错。我见过一个项目，上线前架构师就把"订单、退款、物流、对账"全部做成了抽象类，结果三个月之后退货流程一大改，所有抽象层的接口被迫跟着改，下游子类全部重写，那个"宏伟设计"反而成了最大的技术债。
4. 好的抽象长什么样：一张可以自查的清单
假设你按照上面的节奏，抽了一轮抽象，那怎么判断你抽得好不好？这里有一个容易让人迷失的点：很多人喜欢用"符不符合某种设计模式""类图画得帅不帅"来评判抽象，我的标准反而非常朴素，就三条。
4.1 换实现不换调用方，这叫稳
最直观的标准：底层实现换了一遍，调用方代码不用动一行，说明你把变化点封对了。
举个例子，你的日志模块最开始是往文件里写的，统一提供了log.info(...)、log.error(...)这样的接口。某个迭代里，线上要求把日志推送到日志中心，你只需要在模块内部把"写文件"的实现替换成"走网络推送"，业务代码毫无感知。这就说明当初的抽象把"日志输出方式"这个变化点成功隔离了。
反过来，如果每次底层一换，调用方就要跟着改参数、改调用顺序，那就说明抽象层把不该暴露的细节暴露出来了。所谓的抽象好坏，在这一点上跟"开闭原则"是同一个意思：对扩展开放、对修改关闭——这个"修改关闭"，指的就是调用方代码不被动。
4.2 加一个新变化只需要"增"，不需要"改"
第二点同样关键，而且可以直接自查：你新增一个具体类/实现时，要不要动已有的父类或者兄弟类？
好的抽象，新增实现就像插一根新的充电线——插头插进同一个接口，通电完成，原来的线一根都不用动。不好的抽象，你新加一个"礼品卡支付"，发现父类的authorize方法签名要加一个参数，于是所有已存在的支付子类都得跟着改签名，这就说明抽象抽取的"共性"并不到位。
实操中我给自己定了一条规则：同一个抽象接口下，**只要出现第三次"新增子类导致老代码改动"，就必须回头重新审视抽象边界，而不是继续打补丁。**因为在这个位置，共性没有真正被提炼出来，而是被硬压进了一个共同的接口。
4.3 抽象的名字必须精准
这第三条最容易被忽略，但我认为是长期维护里最能暴露问题的：抽象层的命名要能精确反映它承载的"唯一一种变化"。
通常接口暴露的是业务领域的概念名，像DataSource、PaymentChannel、NotificationSender，一个名字对应一种职责。如果你发现自己给类起名字的时候很纠结，"这个类既要处理支付，又要处理发票，还得带一点物流查询"——那不用怀疑，这个抽象的边界一定是歪的。名字纠结，本质上是因为抽象承载了多种变化维度，脑子都感知到了，但没有落成一个清晰的词。
Python 标准库里其实有很多值得学习的抽象定义。比如collections.abc下的几个抽象基类：Iterable约束"能被迭代"这一个能力，Container约束"能判断成员包含关系"这一个能力，Sized约束"有长度"这一个能力。每一个抽象基类都对应一种单一的、清晰的能力。一个具体的类可以用class MyCollection(Iterable, Container)来组合，但每一个抽象层本身，都必须是单一概念的。这就是抽象命名的教科书。
| 自查项 | 具体动作 | 理想状态 |
|---|---|---|
| 变更隔离 | 替换底层实现，不碰调用方代码 | 调用方零改动 |
| 扩展成本 | 新增一个子类/实现 | 只新增，不修改已有代码 |
| 命名精度 | 问自己"这个抽象承载了几种变化" | 一种，名字能直接说清 |
| 子类落地 | 检查已有子类中是否存在用不上的方法 | 没有空方法、没有 NotImplementedError |
5. 抽象过度的三种病，以及止损实操
讲完"什么时候该抽象"，还必须讲"什么时候不该抽象"。因为 OOP 这条路上，走过头比走不到更常见。我见过太多团队吃过抽象过度的亏，甚至我自己也亲手埋过这种雷。这里给你盘点三种最常见的"抽象病"。
5.1 病一："为未来预留"的抽象
这种病的典型症状是：项目里只有一个实现，但代码外面套了三层抽象。你问作者为什么这么做，他会说："以后可能要换方案嘛，先留好扩展点。"
我在一个内部项目里见过最典型的例子：缓存模块只有一个 Redis 实现，但设计了CacheInterface抽象基类，还有一个工厂函数负责"根据配置选择缓存实现"。听起来挺合理对吧？问题是两年代码运行下来，从来只有 Redis 这一条路被走到。结果就是每次有人要改缓存逻辑，都得穿过三层源码才能定位到 Redis 那个类。这个抽象不是帮了忙，而是变成了纯粹的阅读障碍。
止损动作很简单：
- 先把抽象层下的唯一实现找出来，确认真的只有一个。
- 把工厂函数改成直接使用实现类，删掉抽象基类。
- 把抽象基类里唯一实现中用不到的方法一并删掉。
- 运行测试，确认功能不变。
我知道有人舍不得删，觉得"万一以后要用呢"？我的回答是：**抽象是可逆的操作，担心以后要用，等以后真的出现了第二个实现，你再用第 3 章的三步法重新抽象也不迟。**留着过度抽象，等于让所有同事每天为你的"万一"买单。
5.2 病二："全家桶"抽象
第二种病更隐蔽——一个抽象基类聚合了多种本不相关的能力。最典型的现象是：子类里出现一堆raise NotImplementedError。子类一多，你翻代码时看到几个空方法、几个抛异常的 stub，就可以断定你抽错边界了。
举一个实际例子，一个DataSource抽象基类，定义了connect()、read()、write()、parse()、validate()五个方法。设计者当时觉得"所有数据源都要做这些事"。结果做"日志数据源"时，这个子类只需要read()和parse()，connect()根本不存在、write()永远不让用。于是你被迫在子类里这样写：
class LogDataSource(DataSource): def connect(self): raise NotImplementedError("日志数据源无需连接") def write(self, data): raise NotImplementedError("日志数据源不可写") ...这种代码一看就是病。止损的方法是拆分抽象：把DataSource拆成ReadableDataSource、WriteableDataSource、ConnectableDataSource多个单一能力的接口，子类组合需要的部分。这跟 Python 标准库collections.abc的做法是一脉相承的——小而独立的抽象，通过组合使用，这是维护性最好的形态。
5.3 病三：接口不稳定，反复改签名
第三种病出现在抽象时机太早的时候：抽象层定义了两周，接口签名就改了三次，所有子类跟着来回改。与其说这是抽象问题，不如说是"你根本还不知道业务长什么样就急着定了边界"。
我处理过最令人抓狂的一个案例：某个支付对接模块的抽象基类叫PayProvider，里面定义了authorize(token, amount)、capture(token, amount)。等到真正接入微信支付时发现，微信支付是用户扫码、异步回调，根本没有"预授权-捕获"这两个动作。于是团队硬给微信这个实现加了个空 shell，最后整个抽象名存实亡。
面对这种病，止损动作跟你想的相反——**不是再包一层抽象，而是先拆掉抽象。**把接口去掉，直接让具体的微信支付类、支付宝类裸奔一段时间，等业务跑顺、真实使用经验攒到三四个渠道了，再回头看哪些方法是各个渠道都有的，重新做抽象。这恰恰呼应了第 1 章的核心观点：抽象必须建立在真实使用经验之上，没有经验就强行抽象，接口一定翻车成筛子。
5.4 止损的通用步骤
不管中了哪种病，止损流程我都建议按这个顺序走：
- 停止扩散：先冻结该项抽象下新增的实现，避免病态范围扩大。
- 写行为测试：把现有功能用测试固定住，确保重构不改变外部行为。
- 逐层拆除抽象：每次拆一层就运行测试，观察调用方是否有感知。真有必要保留的抽象，会在一层层的拆除中自动暴露出来。
- 记录教训：把这段经历写成代码注释或团队文档，说明"为什么这里不抽象"，防止后来人又拍脑袋加上去。
说起来有点残酷，但我在十个项目里看到，最后能被时间验证留下来的抽象，基本都是"被三个使用场景逼出来的"，而那些启动阶段就精心设计好的抽象，多数变成了后续迭代路上的绊脚石。
给所有人的一句总结式体会
这篇聊下来，最想传达的其实是我自己长期实践得出的一句话：**做项目的时候，别急着当"设计师"，先当好"使用者"——包括自己代码的使用者、模块接口的使用者，以及业务变化的使用者。**把具体的东西反复用起来，把过程里的不适和重复当成信号，抽象就会在你手头自然成型，并且比任何提前规划都更贴合真实业务。
我至今还在自己的项目里维持一个习惯：每个复杂模块旁边，专门留一段注释，写清楚"这个模块目前只有一两个使用场景，暂不抽象；当第三个场景出现时，应该按下述方向做抽象"。这份清单既是给自己的提醒，也是在给团队传递一个共识——抽象不是越早越好、越多越好，而是越"用过"越好。这个方法也成了我做技术评审时推荐给同事频率最高的一条经验，希望对你同样管用。
