1. 为什么“适应设计模式”值得单独拎出来聊很多人学设计模式有个通病一上来就啃单例、工厂、观察者这些“明星模式”结果代码里到处是生搬硬套的痕迹明明三行能写完的逻辑非要套两层接口加一个抽象类。我早年也踩过这个坑后来回头翻《图解设计模式》这本书才发现作者把“适应设计模式”放在最前面讲是有讲究的——它解决的不是“怎么造对象”而是“现有东西不匹配怎么让它匹配上”的问题这是日常开发里出现频率最高、也最容易被写丑的一类需求。所谓“适应设计模式”核心就两个适配器模式Adapter和模板方法模式Template Method。前者处理的是“接口对不上”的尴尬后者处理的是“流程骨架固定、细节各自不同”的重复。这两个模式看起来简单但真正写对、写干净的人并不多。我见过太多项目里适配器被写成了“万能转换层”模板方法被写成了“继承地狱”最后维护成本比不用模式还高。这篇笔记面向的是已经能写业务代码、但对设计模式还停留在“知道名字”阶段的开发者。我会把这两个模式的适用边界、实现细节、参数取舍、踩坑经验全部摊开讲配上可以直接抄的代码结构和排查表。读完你至少能做到两件事第一看到“接口不兼容”的需求时能判断该不该上适配器第二看到“流程重复但步骤有差异”的代码时能判断模板方法是不是最优解而不是条件反射地抽父类。需要提前说明的是书里的示例偏理论我下面补充的实操细节、参数计算和排查思路是基于常见工程实践做的合理演绎不是书里原文但逻辑上站得住脚你可以直接拿去对照自己的代码。2. 适配器模式把“对不上”的接口接起来2.1 核心思路与选型逻辑适配器模式的本质是在不修改现有类的前提下让一个类的接口变成调用方期望的另一个接口。生活里的类比很好理解你出国带了个两脚插头墙上是三孔插座你不需要改造墙也不需要拆了插头中间加一个转换头就行。转换头就是适配器墙和插头都不动。为什么强调“不修改现有类”因为实际项目里被适配的那一方往往是第三方库、遗留代码、或者别的团队维护的模块你根本没有修改权限或者改了会引发连锁回归。这时候适配器就是唯一干净的解法。选型上有个关键判断你是要“转换接口”还是要“增强功能”如果只是接口签名对不上用适配器如果是要在原有行为上叠加日志、缓存、权限校验那更接近装饰器或代理别混用。我见过有人把鉴权逻辑塞进适配器里结果适配器既做转换又做拦截职责糊成一团后来排查一个权限 bug 花了两天。适配器有两种实现形态选哪种取决于被适配对象的性质形态实现方式适用场景代价类适配器继承被适配类同时实现目标接口被适配类是稳定的、可继承的受单继承限制耦合较紧对象适配器持有被适配类的实例实现目标接口被适配类不可继承、或需要适配多个实例多一层委托调用但更灵活绝大多数工程场景我推荐对象适配器原因很实在组合优于继承被适配类换成另一个实现时适配器内部改一行字段类型就行继承方案得整个类重写。而且很多语言里类只能单继承一旦继承了被适配类就没法再继承别的扩展性直接锁死。2.2 接口设计与委托细节写适配器最容易犯的错是把适配器写成“大杂烩”——目标接口里塞了七八个方法适配器里每个方法都做一堆转换逻辑。正确的做法是目标接口要窄只暴露调用方真正需要的方法。接口越窄适配器越薄测试越好写。举个具体结构。假设调用方期望的接口是DataReader只有一个readAll()方法返回统一格式的数据而现有的是某个老模块的LegacyFetcher它提供的是fetchChunk(index)分页拉取。适配器要做的是把分页拉取循环拼成一次性返回class DataReader: def read_all(self): raise NotImplementedError class LegacyFetcher: def fetch_chunk(self, index): # 老模块的分页接口返回一批数据 ... class FetcherAdapter(DataReader): def __init__(self, fetcher, page_size100): self._fetcher fetcher self._page_size page_size def read_all(self): result [] index 0 while True: chunk self._fetcher.fetch_chunk(index) if not chunk: break result.extend(chunk) index 1 return result这段代码里有个容易被忽略的点循环终止条件。老接口用“返回空”表示结束还是用“返回数量小于页大小”表示结束必须确认清楚。我踩过一次坑老接口在最后一页恰好返回满页数据下一轮才返回空如果按“小于页大小”判断就会漏掉最后一页。这种细节书里不会写但线上会出事。委托调用的另一个要点是异常转换。被适配的老模块可能抛自己的异常类型调用方不认识。适配器有责任把异常翻译成目标接口约定内的异常否则调用方得同时 catch 两套异常体系适配就白做了。转换时保留原始异常作为 cause方便排查。注意适配器只做“翻译”不做“业务决策”。如果转换过程中需要判断业务规则比如某类数据要过滤那说明目标接口设计有问题应该把过滤逻辑放到调用方或独立的策略里别塞进适配器。2.3 一个完整的落地示例与参数取舍假设有个报表导出功能调用方统一调用Exporter.export(data)但底层要对接两种老导出器一种按行导出一种按列导出。用适配器统一class Exporter: def export(self, data): raise NotImplementedError class RowExporter: def export_rows(self, rows): ... class ColExporter: def export_cols(self, cols): ... class RowExporterAdapter(Exporter): def __init__(self, exporter): self._exporter exporter def export(self, data): self._exporter.export_rows(data) class ColExporterAdapter(Exporter): def __init__(self, exporter): self._exporter exporter def export(self, data): # 行列转换在这里完成 cols list(zip(*data)) self._exporter.export_cols(cols)这里的参数取舍在于转换成本放在哪。行列转换有内存开销数据量大时zip(*data)会一次性展开。如果数据是流式的就得改成逐块转换。我的经验是单次导出数据超过一万行时别用一次性转换改成生成器逐块喂给老导出器内存峰值能降一个数量级。这个阈值不是拍脑袋是按常见对象内存占用估算的——一万行、每行几十个字段一次性展开大概几十兆加上老导出器内部再复制一份很容易触发内存告警。适配器的测试也有讲究。别只测“转换结果对不对”要重点测边界空数据、单条数据、超大数据、老接口抛异常。我习惯给每个适配器写一个参数化测试把这四种情况全覆盖后面换老模块实现时直接跑一遍心里有底。3. 模板方法模式固定骨架放开细节3.1 什么时候该抽父类什么时候不该模板方法模式的定义很直白父类定义算法骨架把某些步骤延迟到子类实现。但“什么时候该抽”才是真问题。我的判断标准有三条满足两条以上才考虑多个类有相同的流程顺序只是个别步骤实现不同流程顺序本身是业务约束不允许子类随意调整比如必须先校验再落库重复的骨架代码占比超过一半复制粘贴已经明显拖累维护。反过来如果只是几个方法长得像流程其实各走各的那就别抽父类抽个工具函数或者策略类更合适。我见过一个项目把“发通知”抽成模板方法结果邮件通知、短信通知、站内信通知的流程差异巨大父类里全是if type ...的分支模板方法彻底退化成条件判断还不如不抽。模板方法的价值在于用继承锁住顺序用抽象方法放开细节。锁住顺序这点很关键——它把“流程正确性”从每个子类的责任变成了父类的责任子类想改顺序都改不了从结构上杜绝了“某个子类忘了先校验”这类 bug。3.2 钩子方法的妙用与陷阱模板方法里除了必须实现的抽象步骤还有一类叫钩子方法Hook父类给个默认空实现子类按需覆盖。钩子的作用是让骨架在固定顺序下保留可选扩展点避免为了一个小差异就新开一个抽象方法逼所有子类实现。典型结构class ImportTask: def run(self): self.validate() data self.load() self.before_save(data) self.save(data) self.after_save(data) def validate(self): raise NotImplementedError def load(self): raise NotImplementedError def save(self, data): raise NotImplementedError def before_save(self, data): pass # 钩子默认不做 def after_save(self, data): pass # 钩子默认不做before_save和after_save就是钩子。某个子类需要在保存前做数据清洗覆盖before_save即可其他子类不受影响。钩子的陷阱在于默认实现不能有副作用。我见过有人在钩子里默认写了“发送通知”结果所有子类都莫名其妙发了一堆通知。钩子的默认实现必须是“什么都不做”或者“做最保守的事”这是铁律。另一个陷阱是钩子调用时机。before_save到底是在数据加载完之后、保存之前还是在保存动作内部不同理解会导致子类覆盖后行为不一致。解决办法是在父类里把钩子调用位置写死并加注释同时在文档里明确“钩子执行时 data 处于什么状态”。这种约定比代码本身更重要。3.3 继承层级的控制与组合替代方案模板方法用多了继承层级会膨胀。三层、四层继承下来想找一个方法到底在哪实现得一路往上翻。控制层级的手段有两个第一抽象方法数量控制在 3 到 5 个。超过 5 个说明这个骨架承担了太多职责应该拆成两个模板。我做过一个统计实际项目里超过 5 个抽象步骤的模板方法子类实现完整率明显下降经常有人漏实现某个步骤因为实在记不住。第二优先用组合替代深层继承。如果发现某个子类只是想替换其中一个步骤而其他步骤和兄弟类完全一样那可以考虑把这个步骤抽成一个策略对象通过构造函数注入而不是新开一个子类。这样继承树保持扁平变化点用组合表达。class ImportTask: def __init__(self, validator, loader, saver): self._validator validator self._loader loader self._saver saver def run(self): self._validator.validate() data self._loader.load() self._saver.save(data)这种写法牺牲了“继承锁顺序”的强制性但换来了更灵活的组装。选择哪种取决于流程顺序是否真的不允许变。如果顺序是硬约束用继承如果顺序可能因场景调整用组合加显式调用。注意模板方法里的抽象方法命名要体现“步骤语义”不要用doSomething1、step2这种。名字本身就是文档validateInput、persistResult比step1、step2可读性高一个档次子类实现时也不容易搞错顺序。4. 两个模式的协作与边界划分4.1 适配器套在模板方法里的组合用法实际项目里这两个模式经常一起出现。典型场景一个固定的处理流程模板方法其中某个步骤需要对接多种外部接口适配器。比如数据同步任务骨架是“拉取→转换→写入”拉取步骤对接三种不同的数据源每种数据源接口都不一样。结构上模板方法定义fetch()抽象步骤每个数据源对应一个子类子类内部持有一个适配器把各自的数据源接口适配成统一的fetch()语义。这样流程顺序由父类锁死数据源差异由适配器消化职责分得很清。这种组合的好处是变化被隔离在最小单元。新增一个数据源只需要写一个适配器加一个薄薄的子类父类和其他子类一行不动。坏处是类数量增加所以适合数据源种类有限且稳定的场景。如果数据源是动态注册的那更适合用策略模式加工厂而不是继承。4.2 别把适配器写成“万能胶”适配器最容易被滥用的地方是拿它去“抹平”本不该抹平的差异。比如两个模块的业务语义根本不同硬用适配器包装成同一个接口调用方以为拿到的是同质数据实际行为天差地别这种适配比不适配更危险。判断标准很简单适配前后目标接口的语义必须一致。如果适配器内部需要做大量业务判断才能让行为对齐那说明这两个东西本来就不该用同一个接口应该在上层用分支处理或者重新设计接口。适配器解决的是“签名不匹配”不是“语义不匹配”。4.3 模板方法的“反模式”信号有几个信号出现时说明模板方法用歪了该考虑重构父类里出现大量if self.type ...的分支——说明差异没下沉到子类骨架被污染了子类大量覆盖钩子方法且覆盖逻辑互相冲突——说明钩子设计粒度不对应该拆成独立步骤新增一个子类需要改动父类——说明骨架不够抽象或者变化点没找对。我个人的经验是模板方法写完后如果新增第二个子类时不需要动父类那设计基本过关如果新增时被迫改父类趁早重构越晚改成本越高。5. 实操排查那些书里不会写的坑5.1 适配器常见问题速查现象可能原因排查方向适配后数据缺最后一批循环终止条件判断错确认老接口的结束信号是空返回还是数量不足调用方收到不认识的异常异常未转换适配器内 catch 并包装成目标异常内存暴涨一次性转换大数据改流式/分块转换设阈值适配器越来越厚目标接口过宽或塞了业务逻辑收窄接口业务逻辑外移换老模块实现后行为变了适配器依赖了老模块的隐式行为补边界测试显式声明依赖5.2 模板方法常见问题速查现象可能原因排查方向子类漏实现某步骤抽象方法过多控制在 5 个以内或拆模板钩子产生意外副作用钩子默认实现不保守默认实现改为空操作父类分支爆炸差异未下沉把分支逻辑移到子类或策略继承层级过深用继承表达组合变化点改注入策略对象流程顺序被绕过子类直接调内部方法骨架方法设为不可覆盖内部步骤 protected5.3 我踩过的两个具体坑第一个坑是适配器的线程安全。有次适配器内部缓存了分页游标多线程调用时游标串了数据重复。后来改成每次调用独立游标问题消失。教训是适配器如果有内部状态必须明确它是不是线程安全的不确定就做成无状态。第二个坑是模板方法的构造顺序。父类构造函数里调用了抽象方法子类字段还没初始化拿到的是空值。这个坑很隐蔽因为单测覆盖不到构造阶段的调用。解决办法是父类构造函数只做字段赋值任何依赖子类实现的方法调用都放到run()这类显式入口里。6. 把模式用“薄”而不是用“厚”写到这里我想说一个贯穿始终的观点适配器和模板方法都是结构性模式它们的价值在于让代码结构清晰而不是让代码显得高级。判断用得好不好标准只有一个——后来的人改需求时是觉得顺手还是觉得碍事。适配器要薄薄到一眼能看出它只是翻译模板方法要稳稳到新增子类不用碰父类。一旦发现适配器里堆满业务判断、模板方法里全是条件分支那就是信号要么需求本身不适合这个模式要么抽象层次找错了。这时候退回去用最朴素的写法往往比硬套模式更明智。我在实际项目里的体会是这两个模式最适合用在边界清晰、变化可预期的地方。接口对接的边界、流程骨架的边界一旦划清楚模式就是顺理成章的事边界没划清就上模式等于给混乱加了一层包装后面拆起来更疼。所以每次动手前我会先问自己一句这个“不适应”是暂时的还是长期的暂时的直接写分支长期的才值得上适配器或模板方法。这个判断花不了几分钟但能省掉后面大量的重构。