1. 模板方法模式是怎么解决Qt开发里的重复流程的1.1 复制粘贴改到崩溃的场面你大概率见过做Qt开发的都知道最让人头疼的不是功能做不出来而是同一个套路换着界面反复出现。我之前在某个跨平台项目里就遇到过典型场景程序里有好几个数据采集窗口每个窗口都是“打开设备、配置参数、采集数据、刷新曲线、保存结果”这么一套流程但每个窗口拿到的设备不一样配置项不一样保存格式也不一样。一开始大家图快直接复制粘贴改改函数名就交差了。功能倒是能跑但问题全堆在后面。比如产品经理提了一个需求某个新窗口在采集结束后要弹个提示框。你一看代码好嘛得去那个窗口自己的流程里加逻辑。又过了一周需求变成“所有窗口在配置参数前都要做一次环境自检”于是你不得不打开三四个界面文件挨个找到流程位置插入一模一样的自检代码。改到后来你自己都分不清哪个窗口改过、哪个忘记了。更别提三个窗口由三个人维护的时候每个人对流程顺序的理解还不一样有人说应该先保存后处理数据有人说应该先处理后保存吵来吵去最后各写各的。这种场景下模板方法模式就是来解决问题的。它做的事情很朴素把“流程骨架”固定下来把“每个环节的具体做法”留给子类去实现。骨架只有一份改流程只动一处环节各自实现扩展业务只加新子类。我用了这个模式重构那套采集窗口之后再遇到“所有窗口都要加自检”这种需求只需要在骨架里加一步所有窗口自动生效再也没有东一个西一个漏改的问题。说个容易混淆的点模板方法模式和C的模板template没有直接关系。前者是设计模式解决的是“流程复用和扩展”的问题后者是语言特性解决的是“类型泛化”的问题。在Qt里用模板方法模式指的一定是前者。1.2 模板方法模式的核心结构拆解模板方法模式的结构不复杂就是一个抽象基类加若干子类。抽象基类里有一个非虚的公共方法通常叫run()、startWork()、execute()之类这个方法负责编排整个算法或业务步骤。步骤里的固定逻辑直接写死在基类里可变逻辑定义成虚函数或纯虚函数交给子类覆盖。还有一个可选项叫钩子方法hook method它在基类里有默认实现默认是空实现或者返回一个安全默认值子类按需覆盖用来在流程的某个时机插入额外逻辑。我用生活里的例子来解释做一道菜有标准流程——备菜、下锅、调味、装盘。备菜和装盘大家差不多但“炒还是煮”“放多少辣”因人而异。如果你把菜谱做成模板固定部分写死可变部分留空给厨师填这就是模板方法模式。厨师不需要知道整个厨房怎么运转只需要把他负责的那一步做好。套到Qt场景里这个结构具体表现为基类定义一个公开的非虚方法作为流程入口。入口方法内部按顺序调用若干个protected或private级别的虚函数。子类只实现这些虚函数不覆盖入口方法本身。这么设计的最大好处是流程控制权集中在基类手里。子类不会因为某个人粗心就把步骤顺序搞乱也不会忘了某个关键环节。团队协作的时候骨架的负责人是唯一的其他人只需要关心自己那一步的实现细节。代码评审的时候也方便基类就是流程的“事实标准”有什么争议对着基类聊不用对比两个窗口代码的差异。1.3 和策略模式、状态模式怎么区分使用写Qt程序的时候很多设计模式的适用范围有重叠容易拿不准。我常常遇到有人问模板方法、策略、状态这三兄弟有什么区别我的判断标准其实就一句话到底是“同一个流程但细节不同”还是“完全不同的几套流程”。模板方法模式强调流程骨架固定、步骤细节可变。重心在“顺序和执行框架”子类是流程的组成部分通过继承来参与流程。策略模式强调整个算法可以整体替换。你有一个上下文对象通过组合持有某个策略对象运行时可以换掉整个算法而不是通过子类化去改步骤。状态模式强调对象在不同状态下采取不同行为。内部状态变化导致行为切换典型例子是状态机驱动的界面流程。举个例子方便大家判断。如果你要对同一份数据做不同格式的导出CSV、JSON、XML三套导出逻辑完全不同这是三套算法适合策略模式。如果你的程序里有多个导入流程都遵循“选文件、解析、校验、入库”的顺序只是解析和校验方式不一样这就是同一个流程的不同细节适合模板方法模式。我个人的口诀是流程场景用模板方法算法替换用策略分支转移用状态。2. Qt框架里到处都有模板方法模式的影子2.1 QWidget的绘制和事件处理就是现成骨架很多用Qt的人其实已经写过模板方法模式只是自己不觉得。最典型的就是自定义控件。你继承QWidget重写paintEvent(QPaintEvent*)这就是在实现模板方法里的具体步骤。Qt框架内部的事件处理流程是固定的事件循环收到绘制事件进入QWidget::event()分发到paintEvent()默认实现调用QStyle完成绘制。我们重写paintEvent()本质上就是在框架定义好的绘制流程里替换其中一步。同理resizeEvent、mousePressEvent、keyPressEvent、enterEvent、leaveEvent这些全都是Qt框架在事件处理模板方法里留给使用者的扩展点。你写一个自定义按钮控件只需要重写paintEvent画外观、重写mousePressEvent记录按下状态、重写mouseReleaseEvent触发点击信号。你完全不用关心窗口系统是怎么把鼠标事件送到控件上的也不用关心重绘区域是怎么裁剪的。这种体验就是模板方法模式在大型框架底层的价值——使用者不用了解全部细节只需要实现少数几个关键步骤功能就能跑起来。我自己写自定义控件的时候特别喜欢利用event()这个总入口做拦截。其实event()也是模板方法里的一步它在所有事件分发之前被调用我可以在里面统一处理自定义事件类型或者做调试日志记录。这个钩子的位置非常靠前可以用来实现很多“横切”逻辑比如全局拖拽、全局快捷键提示不用改控件业务代码。2.2 QAbstractItemModel的若干纯虚函数对应模型流程第二个典型例子是模型视图架构。你写表格、树形列表的时候继承QAbstractTableModel、QAbstractListModel或者QAbstractItemModel需要实现rowCount、columnCount、data这几个核心函数。QTableView的展示逻辑是固定的视图层请求行列数、请求每个单元格的数据角色、根据返回数据绘制界面、处理编辑操作。你实现的那几个函数就是流程中的具体步骤。有人会觉得奇怪为什么Qt非要我把这些函数都实现一遍不能给我一个全能模型吗答案就是因为模板方法模式要求“骨架在框架里细节在子类里”。视图层的刷新调度、缓存管理、索引计算都在框架内部完成不允许你随意破坏你需要负责的只是告诉框架“你的数据长什么样”。这种分工让Qt的模型视图架构非常灵活你可以用一个轻量级模型加载几万行日志数据也可以用另一个模型接上数据库查询结果视图层的代码完全不用动。我记得有次做一个设备日志查询界面刚开始直接用的QStandardItemModel数据量一大就卡。后来改成继承QAbstractTableModel只实现几个必要函数速度立刻上来了。这个改动之所以顺本质上就是Qt已经替你把“表格显示的骨架”定好了我们只需要替换数据获取的步骤。2.3 信号槽和模板方法模式怎么配合学习模板方法模式的时候Qt开发者经常绕不开一个问题信号槽那么方便为什么还要用继承和虚函数我的理解是这两个东西解决的压根不是一个问题。信号槽解决的是“对象之间如何通信”它让两个互不认识的模块能够解耦地通知对方。模板方法模式解决的是“一个对象内部如何处理流程”它让同一套逻辑骨架能够复用到不同子类中。你可以这样理解模板方法负责流程如何走信号槽负责流程走完之后告诉外面的人。两者互不冲突反而是天然搭挡。我在实践里经常这么组合使用在基类的模板方法里每个关键步骤完成之后emit一个信号子类覆盖步骤函数时可以在自己的逻辑里做业务处理外部模块通过connect接住信号来刷新界面、更新状态栏、弹日志窗口。这样做的好处是骨架不依赖具体业务对象它只负责“把流程走完并发出通知”至于谁关心通知基类完全不用知道。2.4 自绘控件和动画系统里的扩展点如果说前面那些例子还是偏框架层面那自绘控件和动画系统就是大家动手写代码时最常接触的模板方法。写过基于QGraphicsView的编辑器或者大屏可视化程序的人应该很有体感QGraphicsItem的boundingRect()、paint()、shape()三个函数就是QGraphicsView渲染流程里的三个模板步骤。视图层在重绘时先调用boundingRect()决定刷新范围再用shape()做碰撞检测和选中判断最后用paint()完成实际绘制。你只需要把这三个函数实现好一个自定义图元就能被场景管理、选中、拖拽、碰撞检测非常省心。动画系统也是一个容易被忽略的例子。QAbstractAnimation内部实现了动画的状态切换、启停控制、帧调度留给子类的核心纯虚函数是updateCurrentTime()你只需要告诉它“当前时间点动画该是什么状态”。QVariantAnimation甚至把这一层也封装好了你只需要提供startValue、endValue和插值函数。这种层层下放的骨架设计跟模板方法模式如出一辙。我做粒子特效或者图表动画的时候特别喜欢继承QVariantAnimation重写updateCurrentTime用一个QPainter绘制每一帧。整个动画循环的控制逻辑不需要我操心我只管画。Debug的时候只需要看updateCurrentTime收到的当前值对不对排查复杂度一下子降下来。3. 实战一用模板方法模式重构采集窗口的重复流程3.1 场景描述和基类设计为了让这套方法论落地我拿一个具体的例子来讲。假设项目里有三个界面温度采集界面、振动采集界面、图像采集界面。三者功能不同但主流程几乎一致初始化设备连接加载或设置采集参数执行采集处理并展示数据保存结果释放资源在没有模板方法模式之前每个界面各自的代码结构大致是构造函数里创建UI控件某个按钮的点击槽里写一长串流程代码最后结束的时候手动清理资源。看起来好像挺好但三个界面之间的逻辑对比会让你非常痛苦尤其是流程要变动的时候。重构方案是创建一个抽象基类假设叫AbstractAcquireWidget继承自QWidget。基类定义一个非虚的公共方法startWork()它是所有采集任务的统一入口负责按顺序调用几个纯虚函数和钩子函数。子类只需要实现具体步骤。类的大致定义如下class AbstractAcquireWidget : public QWidget { Q_OBJECT public: explicit AbstractAcquireWidget(QWidget *parent nullptr); virtual ~AbstractAcquireWidget(); // 流程入口固定顺序不允许子类覆盖 void startWork(); // 钩子方法默认安全实现子类按需覆盖 virtual bool preCheck(); virtual void afterAcquire(); signals: void workStarted(); void workFinished(); void errorOccurred(const QString msg); protected: // 子类必须实现的步骤函数 virtual bool initDevice() 0; virtual bool setupParams() 0; virtual bool acquireData() 0; virtual void processData() 0; virtual bool saveResult() 0; virtual void releaseDevice() 0; };这个设计里最关键的一个点是把入口方法startWork()做成非虚函数。为什么非要非虚因为一旦它是虚函数子类就有可能覆盖它那流程顺序就不再由基类统一控制了模板方法就失去意义。真正意义上的“模板”必须让流程骨架在基类里保持固定。3.2 骨架方法实现控制顺序、失败中断和资源清理startWork()的实现需要仔细打磨既要保证步骤按序执行又要在出错时能中断还要保证资源不被泄漏。我用的方案是用bool返回值表示每一步是否成功失败就立刻停住走错误信号和资源清理不让流程继续往下跑。实现如下void AbstractAcquireWidget::startWork() { emit workStarted(); if (!preCheck()) { emit errorOccurred(tr(设备预检未通过)); return; } if (!initDevice()) { emit errorOccurred(tr(设备初始化失败)); return; } if (!setupParams()) { releaseDevice(); emit errorOccurred(tr(参数配置失败)); return; } if (!acquireData()) { releaseDevice(); emit errorOccurred(tr(数据采集失败)); return; } processData(); if (!saveResult()) { emit errorOccurred(tr(结果保存失败)); } afterAcquire(); releaseDevice(); emit workFinished(); }这段代码有几个细节值得展开讲。第一preCheck()是钩子方法默认返回true。为什么是钩子而不是纯虚函数因为不是每个设备都需要预检。温度采集可能不需要预检图像采集可能要检查相机是否被占用振动采集可能要确认传感器连接正常。如果用纯虚函数强制实现所有子类都得写一个空实现纯属浪费。用钩子方法只需要在需要的子类里覆盖不需要处理的子类什么都不用管基类给一个安全默认值。第二错误分支的分布要仔细检查。我在initDevice失败后没有调用releaseDevice()因为初始化失败往往意味着资源还没有创建但setupParams失败和acquireData失败时资源已经创建了必须释放。很多初学者在写这类流程时常常在某一个分支忘掉清理导致设备句柄泄漏。这个错误分布的错误分支清理点我建议画个小表格对照着检查。第三正常流程里releaseDevice()放在afterAcquire()之后。因为afterAcquire()可能还需要读取设备残留状态或者生成最终报告提前释放会导致信息不全。3.3 子类扩展温度采集界面的具体实现基类设计好了写子类就非常机械。创建一个TemperatureAcquireWidget继承AbstractAcquireWidget构造函数里创建UI控件并连接信号具体的设备操作塞进各个虚函数里。class TemperatureAcquireWidget : public AbstractAcquireWidget { Q_OBJECT public: explicit TemperatureAcquireWidget(QWidget *parent nullptr); protected: bool initDevice() override; bool setupParams() override; bool acquireData() override; void processData() override; bool saveResult() override; void releaseDevice() override; };initDevice()里打开串口或者USB设备创建设备驱动句柄。setupParams()里从界面控件读取温度上下限、采样周期、通道号等配置组织成参数结构体。acquireData()里调用驱动接口连续读取N组温度值存到成员变量里。processData()把原始温度值转成曲线需要的QVariant列表刷新QCustomPlot或者QChart。saveResult()弹文件保存对话框把数据写成CSV或者Excel格式。releaseDevice()里关闭句柄把指针置空。这些步骤的具体实现会因为设备型号而完全不同但它们的共同特点是都是“某个步骤的具体内容”而不是“流程的控制逻辑”。子类的代码里几乎看不到if-else套流程也不需要关心上一阶段成功失败因为骨架已经保证了“没成功就不会走到你这里”。3.4 新增一种设备界面时的工作量重构完成之后加一个气体检测界面需要做什么只需要这样几步新建GasDetectWidget继承AbstractAcquireWidget。实现initDevice、setupParams、acquireData、processData、saveResult、releaseDevice这六个纯虚函数。构造函数里创建UI控件。把这个widget加入主窗体tab页。接收workStarted、workFinished、errorOccurred信号绑定到界面提示和状态栏。整个过程的核心设备对接代码还是得写但流程控制部分一行都不用动。我在模拟项目X里做过一次对比原来加一个新采集界面大概要两天重构之后只花了半天省下的时间主要就是不用再复制粘贴流程代码、不用来回排查三个窗口的流程差异了。关于虚函数的选择我有个经验尽可能不要在骨架里放置“带默认业务逻辑的虚函数”。容易出现的坏味道是基类里给了一个可用但不完全正确的默认实现子类忘掉覆盖程序能运行但行为不对排查起来非常费劲。要么纯虚函数强制实现要么钩子函数给空的或者保守的默认值并明确注释“默认不做处理”。4. 实战二把模板方法用在Qt模型视图架构的数据展示上4.1 一个能复用的表格基类除了采集流程这种业务场景模板方法在Qt的模型视图三件套里也经常能派上大用场。假设项目里要维护好几种设备表格温度设备表、振动设备表、气体设备表。每种设备的列不同、单元格内容不同、编辑行为不同但表格本身的公共行为完全一致表头样式、排序模式、选中整行、双击编辑、右键菜单。常见做法是在每个界面里塞一个QTableWidget或者QTableView然后各自写一遍填充函数。数据量大了之后这段填充逻辑会非常重复。用模板方法重构可以写一个抽象基类AbstractDeviceTableWidget继承QWidget内部放一个QTableView和一个QAbstractTableModel子类。基类负责创建视图、安装必要的delegate、初始化选择模型具体模型的数据规则留给子类。类设计大致是class AbstractDeviceTableWidget : public QWidget { Q_OBJECT public: explicit AbstractDeviceTableWidget(QWidget *parent nullptr); void setupTable(); void refreshData(); protected: // 默认空实现子类可安装自定义delegate virtual void setupDelegates(QTableView *view); // 子类必须创建自己的数据模型 virtual QAbstractTableModel *createModel() 0; // 子类必须返回要展示的数据 virtual QListQVariantList loadData() 0; // 数据刷新前后的扩展点 virtual void beforeRefresh(); virtual void afterRefresh(); };setupTable()里执行的是固定动作创建一个QTableView设置排序和行为逻辑设置水平表头属性然后把createModel()创建的模型安装到视图上再调用setupDelegates()让子类有机会补充delegate。refreshData()先把旧数据清空然后从loadData()取新数据塞进模型里刷新视图最后调用afterRefresh()。这么设计之后再来一种设备表只需要实现两样东西一个数据模型子类负责根据行列号返回单元格文本、对齐、图标、编辑角色一个loadData()负责从设备数据源里取出QVariantList列表。4.2 钩子方法怎么满足个性化需求设备表通常会有一些“破坏共性”的个性化需求。比如有一种设备需要在第一列前面加一列复选框用来多选设备做批量启停。这种“列结构”层面的差异光靠模型不太容易干净地表达。我习惯在基类里加一个virtual int extraColumnCount()默认返回0返回几就表示在表格最前面多出几列额外的操作列。模型内部计算列数的时候把这个值加上第一列的checkState由模型根据设备状态返回。之所以用这种钩子而不是让每个子类都去覆盖setupTable()原因是想把“表格结构”这个共同的形态维持在基类。如果子类可以随意覆盖setupTable()来改变列数那公共的表格配置代码很快就没法维护了。钩子方法的本质是“让骨架知道差异再由骨架统一处理差异”而不是“让子类绕开骨架自己来”。写这种钩子函数我总结了一个节奏先问自己这个差异点影响的范围是局部的还是全局的如果是局部的比如某一列的内容格式变化直接写在模型data()里就行如果是全局的比如整个表格多了几列那才需要基类增加钩子。不要一上来就堆钩子钩子太多会显著提高阅读门槛。4.3 从三个用例抽象出最小虚函数集实际操作中最考验功夫的不是写代码而是怎么找出“最小而足够”的虚函数集合。我的做法是先不急着写基类而是把实际的三个界面拿出来在纸上把每个界面的流程步骤写下来然后对照着找共同点和不同点。比如温度表、振动表、气体表这三个需求共同点是表格的展示、排序、编辑、右键菜单不同点是列定义、数据来源、编辑角色、设备联动逻辑。那虚函数集合就定为createModel()和loadData()这两个纯虚函数加上setupDelegates()、beforeRefresh()、afterRefresh()、extraColumnCount()这四个钩子。这样既覆盖了所有差异点也没有引入不必要的复杂度。我自己在做这个重构的初期吃过亏为了“以后可能用到”给基类加了两个多余的虚函数结果项目里没有子类用到后来有人误以为那是必选的平白填了空实现。经验就是基类的虚函数集合只从真实用例中提取宁缺毋滥。等真正出现新的用例再补充虚函数也不迟。5. 容易被忽视的细节final、虚函数调用约定和骨架稳定性5.1 入口方法可以加finalC11开始支持final关键字Qt完全支持。如果你确定某个流程入口不允许子类重写建议直接在函数声明后面加final。比如void startWork() final;这么做有两个好处。第一编译期就能阻止子类误定义一个同名虚函数避免运行时出现“我以为调的是新逻辑实际走了基类骨架”这种诡异问题。第二给阅读代码的人一个强烈的信号这里是流程控制中心不是扩展点。团队协作的时候这个信号可以减少很多误解。但要注意final只能阻止虚函数重写不能阻止子类定义一个普通的同名非虚函数。所以更稳健的做法是配合命名约定。我习惯把公共入口统一命名成startWork、run之类把内部步骤统一命名成doInit、doAcquire之类的“do前缀”风格或者xxxInternal风格。这样一旦有人在代码里看到调用关系能清楚地区分哪个是流程框架哪个是步骤扩展。5.2 子类覆盖虚函数时到底要不要调用基类版本这是模板方法模式里一个非常容易踩坑的细节。如果基类的某个虚函数有默认实现子类覆盖后可能完全替换掉基类逻辑。有些时候你希望的是“在基类逻辑之外追加一些东西”而不是彻底替换。这个轻重关系常常把握不好。我的处理原则是对于钩子方法如果基类默认实现是空实现子类直接覆盖即可不需要调用基类版本。如果基类里有“必须要执行的公共逻辑”我倾向于把这段公共逻辑留在模板方法内部而不是放在虚函数本身。这样虚函数就可以纯粹作为扩展点不用考虑“先调用父类再干活”这种顺序问题。举例来说如果每个设备在析构清理时都有公共的句柄释放逻辑那这段公共逻辑应该由基类的析构函数统一处理子类只需要在releaseDevice()里做自己的清理。子类重写releaseDevice()时不需要也不应该去调用父类的releaseDevice()。否则一旦有人忘记调用父类版本公共清理逻辑就会丢失而且很难排查因为看起来子类确实“做了清理”。5.3 钩子方法命名要能传达“可选”语义命名这个东西很多人不在意但在模板方法模式里特别重要。钩子方法是“可选扩展点”它的名字应该让使用者一眼就看出来“这个可以不实现”。我用preCheck、beforeRefresh、afterAcquire这种带语义前缀的名字而不是用prepare()这类中性的名字。因为prepare听起来像是必须实现的步骤容易误导。还有一个经验钩子方法的默认值一定是“安全无副作用”的。preCheck()默认返回trueafterAcquire()默认空实现extraColumnCount()默认返回0。如果默认值有副作用比如默认做了一些操作子类偶尔会重复执行那就会导致奇怪的问题。默认值设计得保守整个骨架才好维护。5.4 模板方法模式的单元测试设计模板方法模式跟测试其实是天然的搭档。因为骨架是固定的你可以写一个测试用的最小假子类只实现几个纯虚函数然后验证流程的调用顺序、失败中断行为、信号发射情况基本就可以保证骨架稳定了。我通常的测试方案是在测试工程里定义一个StubAcquireWidget作为假设备用QSignalSpy监听workStarted、workFinished、errorOccurred用一个bool数组记录每一步的调用顺序。测试用例大概有以下几类正常流程所有步骤返回成功验证每个步骤都调用了一次顺序正确最后workFinished信号发出。某一步失败让initDevice返回false验证流程停在对应位置清理函数被调用或者不被调用errorOccurred信号参数正确。重复调用startWork连续调用两次验证第二次调用不会因为第一次的残留状态而出错。钩子默认值不覆盖任何钩子方法验证默认流程正常。这类测试跑起来之后后续如果团队里有人想重排流程顺序或者增加新步骤测试立刻就能报警。改骨架就变得不再心惊胆战了。这个价值在项目后期尤其明显因为它让模板方法模式成为一个“别人可以放心修改的框架”而不是一个“谁碰谁炸的祖宗代码”。6. 常见问题与排查技巧实录6.1 为什么我覆盖了虚函数流程却不走我的实现这是初学者最容易遇到的问题。常见原因有三个第一基类模板方法里调用的不是这个虚函数而是另一个同名重载函数。比如基类里有一个virtual void refresh()还有一个void refresh(int)模板方法内部不小心调的是refresh(int)你在子类里覆盖了refresh()当然不会被触发。排查方式是在模板方法入口打印调用日志看实际调用了哪个函数。第二虚函数签名不一致。子类里定义的新函数参数类型、const限定、返回值跟基类不完全相同编译器不认为这是override。你也许会在编译时收到“隐藏了基类虚函数”的警告也可能一声不吭地通过编译但运行时根本走不到子类实现。第三模板方法本身被覆盖了。如果你在子类里重写了startWork()又没有调用父类的版本那就等于把整个骨架替换掉了。这是模板方法模式最不希望看到的情况所以我才一直强调入口方法要加final。排查建议很简单给子类虚函数加上override关键字一旦签名对不上编译器直接报错。然后在基类模板方法入口和每一个步骤调用处加qDebug打印时序一眼就能看出流程走到哪一步断了。在Qt项目里还经常遇到一种情况类里新增了虚函数或者信号编译时没报错但运行时代码逻辑就是不对。这往往不是设计模式的问题而是构建系统没有重新生成moc文件。遇到“我的实现怎么没被调用”这种诡异问题先干净地重新构建一次再往下查。这个坑跟模板方法没有直接关系但实际项目中经常跟模板方法模式撞在一起很多人排查了半天才发现是缓存构建的问题。6.2 继承层次太深虚函数数量过多怎么办模板方法模式用多了基类会慢慢长胖虚函数越堆越多子类为了满足骨架被迫实现一堆用不到的步骤。这种坏味道说明抽象粒度出了问题。我处理的方法是分而治之。如果发现一个骨架里有超过两套可以独立变化的维度比如“数据来源不同”和“展示方式不同”那就不应该试图用一棵继承树来覆盖所有组合。可以考虑把骨架拆成两层基类比如先定义一个AbstractSourceBase负责数据来源再定义AbstractDisplayWidget负责展示逻辑用组合关系把它们搭起来。模板方法负责第一层的流程组合对象负责第二层的变化。另外一个办法是引入接口类。如果某个子类完全不需要某几个虚函数说明这些虚函数其实不应该在基类里而应该挪到一个更细粒度的接口里。比如AbstractAcquireWidget里如果有几个函数只有图像采集才用而温度采集根本用不到那就可以拆出一个CameraSpecificInterface让图像采集界面额外继承它。这样继承树就不会因为个别子类的特殊逻辑而集体膨胀。6.3 骨架里有耗时操作界面卡住怎么办模板方法模式本身是同步的它假设步骤之间是顺序依赖的。如果某一步是耗时操作比如采集数据要阻塞好几秒直接在startWork()里同步调用就会把界面卡死。Qt里常见的解决办法有两种把耗时步骤丢进QThread或者QtConcurrent里跑或者把骨架本身放到一个独立的工作对象里让工作对象在后台线程执行通过信号把进度传回界面。但这里有个容易忽略的坑模板方法状态的迁移。如果startWork()在前半段启动了异步任务后半段的流程依赖异步结果那startWork()此时已经返回了不能再按顺序调用后续步骤。我的经验是不要试图让startWork()自己同步等待异步结果那会阻塞线程。更稳妥的做法是把流程拆成几个阶段startWork()做前半段异步完成的信号触发时调用一个continueWork()做后半段。实际上这已经是带有状态的手动切分骨架不再是单一函数而是分段的模板逻辑。如果业务里有大量的异步环节而且分支回退很复杂我通常就放弃模板方法模式直接用QStateMachine来管理流程。状态机模型更适合步骤间有复杂跳转的场景。而模板方法模式更适合步骤次序固定、没有太多分支的同步流程。判断的标准很简单流程里出现两个以上异步衔接点就考虑状态机只有一两个耗时步骤阶段切分就够用。6.4 判断标准什么时候用模板方法什么时候直接写最后说一个关于滥用的提醒。模板方法模式不是万能的如果某个流程只在项目里出现一次或者以后根本没有扩展前景强行抽象只会增加读代码的成本。我见过一些团队为了“设计模式覆盖率”把只出现一次的流程也抽象成基类结果别人读代码时要在三层继承关系中来回跳找半天才找到那一段唯一的业务逻辑比直接把流程内联在某一个类里还要累。我自己的判断标准很简单同一个流程出现两次以上并且你能预感到后面会再加一个类似流程这时候才引入模板方法模式。如果只出现一次哪怕代码看起来重复了一点也先写简单直接等到第二个用例真出现时再做抽象。设计模式是为了服务于可维护性不是装饰代码结构。最后再说一点个人心得写Qt项目这些年我越来越觉得模板方法模式是那种“看着简单、用得好的话收益极大、用歪了也极其难受”的模式。骨架定得好整个项目受益骨架定歪了所有子类都跟着遭殃。关键不在于怎么把模式写出来而在于怎么拆分业务步骤、怎么判断变化点。拿到需求先别急着写类先把流程画在纸上标记出哪些步骤在将来可能变化再确定虚函数的集合这套功夫比背模式的定义有用得多。这个思路我在多个跨平台桌面项目里反复验证过也希望看到这里的朋友下次再遇到“多个窗口做类似事情”的老代码时能想起来用模板方法重新梳一轮那种改动之后一身轻松的感觉试过就知道。