面向对象设计：组合模式与策略模式差异与选型

理解组合模式与策略模式的核心职责

组合模式（Composite Pattern）的核心职责在于模糊“整体”与“部分”的边界，使客户端能够以一致的方式处理单个对象和对象组合。它通过定义统一的组件接口，让叶子节点和容器节点实现相同的方法，从而构建出树形层次结构。例如在图形界面或文件系统设计中，文件夹与文件对外暴露相同的操作接口，调用方无需关心当前操作的是目录还是具体文件。策略模式（Strategy Pattern）的核心职责则是将一系列可互换的算法或业务规则封装为独立的策略类，并通过统一的策略接口进行调用。其设计目标是消除冗长的条件分支语句，使算法的变化独立于使用它的客户端。两者虽然都依赖“组合”这一面向对象原则，但组合模式关注的是对象间的结构嵌套与统一遍历，而策略模式关注的是行为的多态替换与运行时动态切换。理解这一根本差异，是后续正确选型与实现的前提。

用典型案例实现两种模式

以文件系统为例实现组合模式：首先定义抽象组件接口FileSystemComponent，包含getName与getSize方法。叶子节点File直接返回自身大小，容器节点Directory则维护一个组件集合，在调用getSize时递归累加子节点大小。客户端只需调用顶层目录的方法，即可透明处理任意深度的嵌套结构。策略模式的实现则以电商折扣计算为例：定义DiscountStrategy接口声明calculate方法。具体策略类如VipDiscountStrategy实现八折逻辑，HolidayDiscountStrategy实现满减逻辑。上下文类OrderContext持有策略接口引用，通过构造函数注入具体策略。在结算时，上下文仅调用strategy.calculate，无需编写if-else判断用户类型。组合对象负责维护子节点集合并转发请求，策略对象则专注单一算法实现，两者职责边界清晰，代码结构高度内聚。

从变化点判断该选组合还是策略

在实际架构设计中，选型应直接锚定需求中的变化点。当业务需求频繁涉及层级结构的增删改查，且要求对整体与局部执行相同操作（如组织架构管理、多级审批流、UI组件树渲染）时，应优先采用组合模式。此时变化点在于节点数量与层级深度，模式通过统一接口屏蔽结构差异。当业务需求表现为多种算法、规则或处理流程需要频繁切换，且这些逻辑互斥或可独立演进（如不同渠道的支付路由、多种排序算法、风控规则引擎）时，应优先采用策略模式。此时变化点在于行为逻辑，模式通过接口隔离实现开闭原则。值得注意的是，两者并非互斥。在复杂系统中常组合使用：例如在报表生成器中，顶层使用组合模式组织表头、表体、表尾等树形组件，而每个组件内部的渲染逻辑则通过策略模式动态注入。通过识别变化维度，可精准匹配设计模式。

验证设计效果并避开常见误用

验证模式有效性的关键在于测试其扩展性与维护成本。对于组合模式，可通过编写单元测试验证新增叶子节点或嵌套容器后，原有遍历与聚合逻辑是否无需修改即可正确运行；若新增节点导致大量类型判断或破坏统一接口，则说明误用了组合模式，应退化为普通聚合。对于策略模式，验证重点在于新增策略类时是否仅需实现接口并注入上下文，而无需改动原有调用链；若策略类之间存在大量共享状态或强耦合，说明抽象过度，应回归简单工厂或条件分支。常见误用包括：将仅有两三层固定层级的普通对象强行套用组合模式，导致接口污染与内存开销；或将仅有两个分支的简单条件判断拆分为策略类，引入不必要的类爆炸。正确的做法是结合单元测试覆盖率与代码圈复杂度指标，在模式引入前后进行对比，确保设计真正服务于业务演进而非过度工程化。