面向数据科学家的7种高级Python设计模式
内容提要
文章介绍七种Python设计模式，用于解决训练代码随项目演进而膨胀的问题：策略模式替换评估分支，适配器统一模型接口，模板方法固定实验流程，观察者解耦日志回调，命令模式封装可排队重跑的任务，外观模式简化子系统调用，代理模式延迟加载昂贵资源。核心原则是：只有当模式能消除反复出现的变更压力、让调用方更简单且边界更易测试时才值得引入，否则普通函数更好。
延伸解读
模式引入的克制原则
文章反复强调一个前提：只有当模式能消除反复出现的变更压力、让调用方更简单且边界更易测试时才值得引入。如果代码不会被其他调用方使用，模式就是多余的仪式，普通函数反而更好。这一原则贯穿七个模式，提醒读者不要为了设计而设计，而是先识别压力再选择模式。
适配器与外观的边界差异
适配器用于让一个不兼容的对象符合本地接口，只翻译接口，不改变语义；外观则简化对整个子系统的访问，本身不做实际工作，只决定调用顺序。文章指出，适配器若掩盖类顺序、阈值或校准差异，就会变成bug生成器；外观若开始承担验证、重试和状态，就会变成新的单体。两者都需保持薄和专注。
观察者与命令的适用场景
观察者将训练循环与日志、仪表盘等解耦，通过冻结事件和回调列表实现，但回调增多后需明确事件顺序、错误处理和成本。命令将一次运行请求封装为冻结数据类，便于排队、重试或跨机器传输，但命令只捕获请求，不捕获环境，数据集版本、代码版本和随机种子仍需显式标识，否则重放可能产生不同模型。
代理模式的运维决策
代理模式延迟加载昂贵资源，保持调用方熟悉的接口，首次使用时才加载真实模型或数据集。但文章警告，代理不会替你做运维决策：缓存失效、线程和进程安全、加载失败时的行为都需要提前明确。一个静默提供过期产物的代理，比显式慢加载更糟糕，因为慢加载至少诚实。
Q&A
为什么训练函数会随着时间变得臃肿？
训练函数最初小而可读，但在共享仓库中经过六个月，会积累模型特定的条件分支、数据源分支、手写的缓存检查和日志调用。每次项目变更都增加一个分支，导致函数膨胀，所有调用者都继承整个烂摊子。
策略模式如何替换评估中的条件分支？
策略模式将评分行为作为可调用对象传入，而不是用if-else分支。例如定义evaluate(y_true, y_pred, scorer)函数，调用时传入不同的评分函数（如accuracy或recall_pos），这样运行器无需知道具体策略，每个评分器可独立测试，添加新评分器只需写函数而无需修改实验代码。
适配器模式在统一模型接口时有什么风险？
适配器模式通过Protocol和薄包装器统一接口，但有两个风险：一是Protocol的静态检查可能遗漏参数类型错误；二是适配器只翻译接口，不处理语义差异（如类别顺序、决策阈值、概率校准），若试图掩盖这些差异，会引入bug。
模板方法模式如何确保实验流程一致？
模板方法模式在基类中固定实验生命周期（如run()方法依次调用load、fit、evaluate、save），子类只需实现可变步骤（如fit()）。这样所有变体都按相同顺序执行，避免复制粘贴导致的偏差，但继承也带来耦合，若步骤需独立变化，应改用策略模式。
观察者模式如何解耦训练循环和日志记录？
观察者模式让训练循环发出不可变事件（如EpochEnded），回调列表处理事件。这样日志记录器、仪表盘等观察者互不知晓，添加新观察者只需追加回调，训练循环不变。但需注意事件顺序、错误处理和成本，避免演变成难以追踪的事件总线。
命令模式如何支持可重跑的训练任务？
命令模式将训练请求封装为冻结的数据类（如TrainModel），包含数据集ID、模型名、配置ID等，并实现execute方法。该对象可序列化、排队、重试，确保执行的请求与记录的一致。但命令只捕获请求，不捕获环境，仍需显式记录数据版本、代码版本和随机种子以保证可复现性。
外观模式和适配器模式有什么区别？
适配器模式让一个不兼容的对象适配本地接口，而外观模式简化对整个子系统的访问。外观模式提供一个任务级方法（如train_and_report），委托给多个组件，本身不执行实际工作，保持轻薄；适配器则只翻译接口。两者都简化调用，但目的不同。
代理模式如何延迟加载昂贵资源？
代理模式保持与真实对象相同的接口（如predict()），在首次调用时才加载真实模型（如三GB的模型），之后重用。这避免了导入时的加载成本。但需明确处理缓存失效、线程安全和加载失败等运维问题，否则可能 silently 提供过时结果。
