Composition Patterns（组合模式）：场景案例

如果你还在犹豫是否要在团队中推行这些模式，不妨看看下面几个真实的故事。它们记录了组合模式是如何在关键时刻拯救项目的。

案例 1：那个“改不动”的万能弹窗

记得上个季度，运营同学提了一个紧急需求：要把现有的“购买成功”弹窗，中间插一个限时优惠券的轮播位。开发小哥哥当时面露难色，因为那个弹窗组件是半年前封装的“黑盒”，结构写得很死。

最终我们决定用“包含关系（Containment）”彻底重构它。现在这个弹窗就像一个中空的展示柜，运营想加个轮播、加个表单、甚至加个小游戏，开发只需要把这些零件往里一丢，逻辑互不干扰。这不仅救了那个需求，还让我们在后来的 618 大促中迭代速度飞快。

案例 2：从“乱套的多彩按钮”到标准库

在公司初期，为了赶进度，我们为不同业务线搞了几十个稍微有点区别的按钮：确认按钮、取消按钮、危险操作按钮。虽然它们长得像，但代码却是各自拷贝的。一调品牌色，全项目都要重改。

通过“特例化（Specialization）”模式，我们只写了一个底层的“基础按钮”，然后快速定制出各个业务线的专属模板。这样即使品牌升级，我们只需要改动那一个“母模”，所有页面就能瞬间同步。这种“单点维护，全域更新”的感觉，让 PM 的排期压力小了一大半。

案例 3：让实时数据“活”起来的魔法

我们在做金融大屏时，很多卡片都需要实时刷新股价。如果给每个卡片都写一套复杂的长连接、错误重连逻辑，代码量大得惊人，而且到处是 Bug。

后来我们尝试用“逻辑包裹类（HOC）”模式，把这些脏活累活全部封装在一个隐形逻辑里。不管你是一个小图标，还是一个大图表，只要套上这层“魔法外衣”，它就立刻拥有了获取实时数据的超能力。这让我们的前端团队在保持 UI 精美的同时，也能把更多的精力放在数据逻辑的打磨上。