结构型模式：七种“搭房子”的智慧

可视化演示

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

适配器模式——“转接头”的不动墙解决方案

老王从欧洲淘回一台智能音箱，兴奋地拆箱，却发现插头是两脚圆头，家里插座是三脚扁孔。快递师傅笑着递给他一个白色小转接头——不用改插座，不用拆音箱，插上就通电。适配器模式（Adapter Pattern）和这个转接头做的事情一模一样。

在软件世界里，新老模块的“插头”和“插座”经常对不上：一个 AI 项目要同时接入三家大模型 API，但每家 SDK 的调用方法长得完全不同。适配器模式的做法是：不改造任何一方，而是引入一个中间翻译层，把一个类的接口转换成客户端期望的另一个接口，让原本无法协作的类顺利合作。

实现上分两种：对象适配器通过组合持有被适配者的引用，灵活且是主流；类适配器通过多继承实现，在支持多继承的语言中使用，Java 中较少用到。无论哪种，客户端看到的始终是一个统一、自己熟悉的方法。

老王的转接头安然地待在墙上，往后每来一件新电器，只需换一个转接头，墙上的插座永远不用动。适配器模式的精髓正是这种“不改造双方、只增加中间翻译层”的优雅——它是系统面对外部变化时最廉价的那堵缓冲墙。

装饰器模式——“软装叠加”的动态魔法

装修师傅对老王拍胸脯：不用砸墙。咱们挂画、贴墙纸、加灯带，一层层叠上去，房子就变高级了。想换风格？撕掉墙纸再贴新的，承重墙毫发无损。装饰器模式（Decorator Pattern）就是这种“软装思维”。

它解决的是一个非常现实的痛点：如果房子要加隔音、加投影、加地暖，总不能每加一种功能就砸墙重砌一种“新墙”吧？面向对象世界里，“砸墙重砌”就是继承——为每一种功能组合创建一个子类，组合一多，类就爆炸。装饰器模式改用叠加：在不改变现有对象结构的前提下，动态地给对象添加新职责。

它的机制很巧妙：装饰器和原始对象实现同一个接口，装饰器内部又持有原始对象。调用时先执行装饰器新增的逻辑，再执行原对象逻辑，就像一层层包上外壳。由于接口一致，客户端感受不到装饰层的存在，这就是“透明装饰”；如果装饰器还额外暴露了新增方法，称为“半透明装饰”。

老王看着一层层变美的房子，完全不需要知道哪一层是哪天加的。装饰器模式让系统拥有了“装修队”式的灵活性：随时加一层、撕一层，主结构永远稳定。这正是它比继承高明的地方——继承是图纸上的设计，装饰器是施工现场的即兴发挥。

代理模式——“管家”的过滤智慧

老王白天在公司忙，装修工、快递员、推销员轮番按门铃。于是他把钥匙交给管家小刘，叮嘱一句：重要的事转达给我，不重要的你看着办。小刘站在门口，先盘问来者意图，再决定是否打扰老王。这就是代理模式（Proxy Pattern）的日常生活原型。

代理模式的核心是为其他对象提供一种替身或占位符，以控制对原对象的访问。它和装饰器长得像，但目的不同：装饰器是“增强功能”，代理是“控制访问”。代理和原对象实现同一接口，客户端持有的其实只是代理，真正干活的默默躲在后面。

常见的有三类：虚拟代理延迟真实对象的创建，直到真要用到资源时才实例化（例如加载超大图片）；保护代理在调用前做权限校验，拦截非法请求；远程代理屏蔽网络传输细节，让本地代码像调本地方法一样调用远方服务。额外，代理也常被用来实现日志、计数、缓存等横切关注点。

老王出差一个月回来，管家小刘把厚厚一沓访客记录递上来，老王只翻了翻重点那几条，剩下的全是管家替他挡掉的噪音。代理模式的价值就在于此：它把“打扰”与“核心”隔离，让客户端面对的资源更干净、更安全、也更快。

外观模式——“智能中控面板”的一键魔法

老王在玄关装了一块智能面板，上面只有几个按钮：“回家模式”“离家模式”“影院模式”。按下“离家模式”，全屋灯光熄灭、空调关闭、窗帘拉上、安防布防——这一切只需要一次触碰。这就是外观模式（Facade Pattern）在生活中的投影。

它的作用是为一组复杂的子系统接口提供一个统一的高层接口。老王不需要知道灯的型号、空调的状态机、窗帘电机的协议，他只需要认识这块面板。外观类把子系统的各个调用编排成业务动作，客户端只依赖外观类，从而大大降低耦合。

外观模式的另一大贡献是切实践行了最少知识原则（也叫迪米特法则）：不与陌生人说话。客户端不要和一堆子系统类打交道，只跟外观这个“老熟人”沟通就好。要注意，外观类并没有禁止客户端访问子系统——它提供的是“便捷通道”，而不是“铁笼子”。

按下“离家模式”的那一刻，老王感受到的是一种被简化后的确定感：无论背后多复杂，入口只有一个，结果总是对的。外观模式教会我们：系统越庞大，越需要主动向外部世界收敛自己的“脸面”，把复杂留给内部，把简单交还用户。

桥接模式——“灯与灯泡”的自由组合

老王逛灯具城，发现灯具分成吊灯、吸顶灯、壁灯（造型维度），灯泡分成 LED、白炽灯、智能调色灯（光源维度）。销售员热情地说：任选组合，自由搭配！老王突然意识到，如果每一种搭配都做成单独的商品，店里要摆 3×3=9 盏样品；而把造型和灯泡分开陈列，只需要 3 盏灯 + 3 种灯泡。

这正是桥接模式（Bridge Pattern）要拆解的难题：当一个类有两个独立变化的维度时，直接使用继承会产生类数量爆炸——M 种抽象 × K 种实现 = M×K 个类。桥接模式的解法简单而深刻：将抽象部分与实现部分分离，让它们各自独立演化，再用一个“桥”连接起来。

具体做法是：抽象类持有实现部分的接口引用，而不是继承具体实现。运行时客户端决定往抽象里注入哪一种实现。这样抽象维度可以扩展为新增的灯具样式，实现维度可以扩展为新型灯泡，互不干扰、互不拖累，充分体现“组合优于继承”的设计信条。

老王最终选了吊灯 + 智能调色灯，一个月后想换吸顶灯，只需要换灯不换灯泡。桥接模式的智慧正在于：识别出系统中那些“各自会变”的维度，把它们从继承的混凝土中拆开，再通过一座灵巧的桥重新连接——变化被隔离，结构却依然牢固。

组合模式——“家族族谱”的递归智慧

老王翻家谱：爷爷在顶端，下面有父亲和叔伯两个孩子分支，父亲下面又有老王和兄弟姐妹。整个家族是一棵树。办家宴时，老王不需要区分“这是个长辈”还是“这是个平辈”——每一个分支都被统一当作“亲戚”对待，族长一声令下，整个大家族递归通知到位。

组合模式（Composite Pattern）将对象组织成树形结构，并让用户对单个对象（叶子）和组合对象（容器）的使用具有一致性。文件系统是最经典的例子：文件夹里有文件夹和文件，用户删除目录时，操作系统递归地把里面所有东西一起删除。

它的结构核心是组件接口（Component），叶子节点（Leaf）和容器节点（Composite）都实现它。容器持有子组件列表并提供 add/remove 方法。透明组合让接口包含管理方法，叶子也要实现它们（但方法体为空或抛异常），好处是客户端统一处理；安全组合则不把管理方法放进公共接口，叶子更安全但需要类型判断。二者各有权衡。

族长通知家宴时，绝不会为“你去找三个叔叔 + 四个堂弟”分别发消息，他只要通知儿子们，儿子再通知孙子们，信息便顺着树的纹路流遍全族。组合模式让递归变成一种日常：用统一的接口，简化了一个层次的复杂性。

享元模式——“共享会议室”的极致复用

老王小区配套了一位精明的物业经理。他发现很多住户都反映“家里来客人没地方招待”，但不能给每户都建会议室啊！于是他改建了一间公共会议室，谁要开家庭聚会就预约使用。空间共用、维护共用，成本瞬间下来一大截。这就是享元模式（Flyweight Pattern）的现实样本。

享元模式运用共享技术有效地支持大量细粒度对象的复用。它的关键洞察是：一个对象的状态可以拆成两部分。内部状态（intrinsic state）是稳定不变、可以共享的——比如会议室的场地本身；外部状态（extrinsic state）是随上下文变化的、由客户端传入的——比如预约的日期、使用的人名。

享元工厂（FlyweightFactory）维护一个共享池：当请求一个享元对象时，若池中已有相同内部状态的对象，直接返回复用，否则创建新对象再放入池中。这样 N 个逻辑对象可能只对应极少数物理实例，极大降低内存消耗。典型应用包括字符串常量池、线程池、游戏中的树叶渲染等。

老王看着物业公告栏上满满的会议室预约表，心里默默算账：以前 50 个家庭都要建会议室得花几百万，现在一间会议室转起来，大家各用各的时间段，互不影响。享元模式告诉我们，世界上很多浪费来自“人人拥有”的幻觉——把不变的东西交给大家共享，把变化的东西留给个人，成本与效率的平衡就这样被解决了。

AI 应用场景

Python 演示

"""结构型模式综合演示：用适配器统一 AI 模型接口，再用装饰器动态加日志。运行：python demo.py"""from functools import wraps  class LLMClient:    """统一接口：所有模型的客户端都长这样"""    def chat(self, prompt):        raise NotImplementedError  class OpenAIAdapter(LLMClient):    def __init__(self, api):        self.api = api     def chat(self, prompt):        # 把统一 chat 翻译成 OpenAI 原生调用        return self.api.create_completion(prompt)  class ClaudeAdapter(LLMClient):    def __init__(self, api):        self.api = api     def chat(self, prompt):        # 把统一 chat 翻译成 Claude 原生调用        return self.api.send_message(prompt)  def with_logging(client):    """装饰器：不改原类，给 chat 动态加一层日志"""    @wraps(client.chat)    def chat(prompt):        print("[log] prompt:", prompt)        return client.chat(prompt)    client.chat = chat    return client  class MockOpenAI:    def create_completion(self, prompt):        return "OpenAI reply: " + prompt  class MockClaude:    def send_message(self, prompt):        return "Claude reply: " + prompt  if __name__ == "__main__":    clients = [        OpenAIAdapter(MockOpenAI()),        ClaudeAdapter(MockClaude()),    ]    for client in clients:        chat = with_logging(client).chat        print(chat("hello"))

1. def chat(self, prompt)统一接口约定，所有适配器必须实现这个签名，客户端只认它。
2. return self.api.create_completion(prompt)适配器内部把统一调用“翻译”成各家 SDK 的原生方法。
3. def with_logging(client)装饰器的核心：接收一个客户端，返回一个被包裹的新方法，原类毫发无损。
4. client.chat = chat展示了 Python 中装饰器模式的动态替换本质：运行时给实例“贴”一层新行为。
5. if __name__ == "__main__":主入口，依次演示两家模型的统一调用和日志增强效果。

常见误区

面试题