设计模式：模式选型

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

选型总原则：先量房，再动工

拿到一套毛坯房，很多人的第一反应是翻装修案例、看建材清单，而不是先拿尺子量房。专业设计师却会先问三个问题：这房子给谁住？常住几个人？未来五年会不会改格局？设计模式选型也是同样的道理——拿到需求不要急着报模式名，先“量房”：需求到底多复杂、会不会变、团队能不能驾驭。量房定风格，风格服务生活，而不是让生活迁就风格。

在软件工程里，KISS（保持简单）、YAGNI（你不会需要它）、高内聚低耦合、按需引入，就是选型的“量房四问”。它们不是四条孤立的格言，而是一个统一的态度：模式的引入必须由现实中真实出现的复杂度证据驱动，而不是由对未来的幻想驱动。

KISS 要求我们选出能让“需求与实现”保持清晰映射的方案；YAGNI 专门狙击“为了也许以后会用到的扩展”而提前设计的冲动。高内聚低耦合是评估候选方案的结构性标尺——无论用不用模式，模块内部的职责要聚拢，模块之间的依赖要松弛。按需引入则是收尾原则：只有当痛点真实出现（创建逻辑失控、接口冲突、算法爆炸），才把对应的模式“请进场”。

记住这四条原则再去翻模式目录，你就像拿着户型图的设计师——不会被眼花缭乱的建材广告带偏，每一步改动都清楚自己为什么做。量房花掉的十分钟，会在之后每一个不返工的夜晚还回来。

创建型选型：谁来买材料

装修最忙的是“买材料”环节。总电闸全屋只有一扇，这是“单例”；需要板材、瓷砖、五金时，你希望有一个统一采购中心，报需求就送货上门，不必知道具体是哪家供应商，这是“工厂”；如果希望全屋材料风格统一，采购中心按“新中式”或“北欧”整套配货，这是“抽象工厂”；而厨房这种复杂项目，要按“拆旧→水电→橱柜→台面→验收”分步施工，这是“建造者”。

创建型模式解决的是“对象怎么产生”的问题。什么时候值得专门为“创建”引入一个模式？判断依据是：创建是否足够复杂、是否散落在各处、产品族是否强调统一。直接用 new 永远是最简单的起点——当创建逻辑开始“遍地开花”时，工厂才值得登场。

单例适合全局唯一、需要共享状态的场景（配置中心、连接池），但要警惕线程安全与测试困难；工厂方法把“创建哪种产品”的决定权交给子类，适合产品类型多变时收敛创建逻辑；抽象工厂进一步约束“产品族”的一致性，适合跨平台 UI 组件这类需要成套搭配的场景；建造者则面向参数多、构建步骤固定的复杂对象，比如一个需要十余项配置的 HTTP 客户端。

材料采购的本质不是“多建几个仓库”，而是“让所有人在唯一入口报需求”。当你在代码里发现十处都在手搓同一个复杂对象的创建流程，就该给装修队配一个统一采购中心了。

结构型选型：不动承重墙的改造

老房子总有不如意：旧插座配不上新电器，墙面太单调想加点层次，怕陌生人进门又不便亲自接待。装修师傅有四种不需要拆承重墙的解法：转接头（适配器）、贴壁纸叠装饰（装饰器）、物业托管钥匙（代理）、前台统一接待（外观）。

结构型模式的共同点是“在不改变原有类内部结构的前提下，通过组合来扩展或适配”。它们回答的问题是：现有代码不能大改，需求却要变，怎么办？

适配器解决“接口不匹配”，把 A 的“方言”翻译成 B 听得懂的“普通话”，典型场景是接入第三方 SDK 时隔离差异；装饰器解决“功能叠加”，避免为每种组合都新建子类而导致的类爆炸，典型如 IO 流的多层包装；代理控制“访问方式”，在真实对象前加一道闸——权限校验、懒加载、远程调用都靠它；外观则给复杂子系统一个极简入口，调用方只跟一个“门面”说话。选型时先问：要解决的是“说不上话”（适配）、“想叠功能”（装饰）、“想管访问”（代理）还是“想省心”（外观）？

好的改造从不砸承重墙。结构型模式的优雅之处在于：老墙还在，功能却像壁纸一样一层层叠上去了。哪天不想要某层“壁纸”，撕掉即可，墙依然完好。

行为型选型：定好家人的协作规则

入住之后，麻烦往往不是墙和电，而是“家里人怎么配合”。晴天晒被、雨天烘干——晾衣方案要能随时换（策略）；门铃一响，客厅、厨房、卧室的人都知道来客了（观察者）；装修工序有固定套路——基层处理、刷底漆、刷面漆、验收，细节各家不同但骨架一致（模板方法）；同样一扇门，开着、关着、反锁时的行为完全不同（状态）。

行为型模式管的是“对象之间的职责分配与协作方式”。它们不改变类的结构，而是重新安排“谁在什么时机做什么”。

策略模式把一族可互换的算法封装起来，让上下文在运行时切换，典型如促销计价、排序算法；观察者模式定义一对多的依赖，主题状态一变就通知所有订阅者，典型如事件总线、消息通知；模板方法把不变流程固化为骨架，把变化点留给子类，典型如数据迁移流程；状态模式把状态相关的行为内聚到各自的状态类中，消灭大量 if-else，典型如订单状态流转。选这四个模式的关键是看“变化的主角是谁”：算法？通知？流程？还是状态？

行为协作的选型，本质是在给家庭成员发“分工说明书”：不变的流程用模板固化，会变的部分抽出来让策略自由替换。家里从此井然有序，来再多的客人也不乱。

决策与权衡：做一张装修预算表

方案定了好几个，最终拍板靠什么？靠预算表。每一项装修增项都写清楚：这房间未来改不改（扩展性）、师傅会不会做（团队熟悉度）、报价多少（复杂度代价）、对居住体验影响多大（性能）。把所有候选方案算一遍总分，最高者中标——注意，中标的不一定是材料最贵的，而是总分最高的。

模式选型的最后一步是量化比较。除了“这个模式能不能解决问题”，还要比较“值不值得为它付出代价”。工程决策从来不是单选题里的唯一正确项，而是加权后的相对最优解。

决策维度通常包括：需求匹配度——模式是否精准命中痛点；扩展性预期——依据真实业务规划而非臆测；性能影响——间接层带来的调用开销是否可接受；维护成本——间接层越多，排查问题越绕；团队熟悉度——没人会的“高级模式”就是负资产。把这些维度加权汇总，得到可比较的分数。同时记住“两害相权”：模式引入的间接性与调试难度，往往比多写几行朴素代码更贵。

预算表的价值不是算出“精确的正确”，而是逼你把每个方案的代价摆到桌面上。装修不超支的秘诀从来不是少花钱，而是每分钱都花得明白。

反模式陷阱：当装修变成拆家

见过最惨的装修翻车：为了“以后可能装电梯”，提前在一楼砸出电梯井，结果验收不过、全楼返工；或者师傅手里只有一把锤子，看啥都像钉子，好好的墙面也要敲两下。装修的灾难很少因为“做少了”，大多因为“做过头了”。

软件工程把这些“做过头”的实践称为反模式。它们看起来很有道理——提前考虑扩展、全面应用模式、追求设计完备——实际上却在给未来制造债务。

常见反模式：过度设计——在简单需求上堆砌抽象层，为臆想的未来买单；模式滥用——把单例当全局变量的遮羞布、把策略模式用在两个固定分支上；忽视简单方案——为了“专业感”拒绝用朴素代码；锤子心态——熟练一种模式后到处套用。技术债务的可怕之处在于它不是线性增长：方案复杂度超出需求越多，债务膨胀得越快。

守住反模式的底线很简单：每次想加一层抽象时，先问自己——这是需求逼我做的，还是我的“职业习惯”逼我做的？装修如此，写代码亦如此。拆过的承重墙，永远不会自己长回来。

AI 应用场景

Python 演示

#!/usr/bin/env python3# 设计模式选型决策器: 根据需求特征评分, 推荐最匹配的模式 PATTERN_PROFILES = {    # 模式名 -> {需求特征: 权重}    "Singleton": {"unique_state": 3, "shared_state": 2, "many_creates": 1},    "Factory":   {"complex_create": 3, "multi_impl": 2, "decouple_call": 1},    "Adapter":   {"iface_mismatch": 3, "reuse_legacy": 2, "compat_old": 1},    "Strategy":  {"algo_variant": 3, "avoid_branches": 2, "switch_runtime": 1},    "Observer":  {"one_to_many": 3, "loose_couple": 2, "event_driven": 1},    "Decorator": {"dynamic_boost": 3, "avoid_explosion": 2, "transparent_add": 1},}  def recommend(needs, top_n=3):    # needs: 需求特征字典, 值为 True 或权重系数    scores = []    for name, profile in PATTERN_PROFILES.items():        total = 0        matched = []        for feature, weight in profile.items():            val = needs.get(feature, 0)            if val:                total += weight * (1 if val is True else val)                matched.append(feature)        scores.append({"pattern": name, "score": total, "matched": matched})    scores.sort(key=lambda x: x["score"], reverse=True)    return scores[:top_n]  def main():    # 场景1: 全局配置中心, 状态全局唯一且需要共享    case_1 = {"unique_state": True, "shared_state": True}    # 场景2: 支付渠道切换, 算法多变且需运行时替换    case_2 = {"algo_variant": True, "avoid_branches": True}    for tag, needs in [("global_config", case_1), ("payment_switch", case_2)]:        print("scenario:", tag)        for r in recommend(needs):            print("  %-10s score=%d matched=%s" % (r["pattern"], r["score"], r["matched"]))        print()  if __name__ == "__main__":    main()

1. PATTERN_PROFILES = {...}定义了每个模式的“画像”：它擅长解决哪些需求特征，权重表示适配程度，对应正文里的模式选型知识库。
2. for feature, weight in profile.items():遍历某个模式的全部特征，逐一核对当前需求是否命中。
3. val = needs.get(feature, 0)安全地读取需求特征值，缺失时按 0 处理，不会因为缺 key 报错。
4. total += weight * (1 if val is True else val)命中就加权计分；如果调用方给了自定义权重系数，就按系数放大。这正对应“决策与权衡”的加权评分公式。
5. scores.sort(key=lambda x: x["score"], reverse=True)按总分从高到低排序，最高分的模式就是“预算表”上性价比最好的候选。
6. for tag, needs in [("global_config", case_1), ...]一次性跑多个测试场景，验证决策器输出是否符合人工判断——全局配置中心应命中单例，支付切换应命中策略。

常见误区

面试题