面向对象组合实战咨询：如何获取普通开关关联的定时开关等扩展实例

方案选型结论 #

结合后续多扩展灵活接入的需求，你梳理的3b（组件持有）方案是最优选择，该实现完全属于面向对象编程范畴，符合面向对象设计的核心原则。

各方案优劣分析 #

• 方案1（普通开关重构为组合类）：直接否决。该方案会破坏现有客户端依赖，且后续新增扩展需要持续修改组合类代码，违反开放封闭原则，扩展性极差。
• 方案2（外部维护关联映射表）：不推荐。该方案将对象关联关系剥离到类外部，破坏了面向对象封装的核心特性，客户端需要同时依赖开关容器和映射表，后续扩展数量增加后映射表维护成本会指数级上升。
• 方案3a（普通开关改造为外观类）：扩展性不足。虽然可以兼容现有客户端代码，但每新增一种扩展能力都需要修改外观类的方法转发逻辑，仍然违反开放封闭原则，长期维护成本高。
• 方案3b（组件持有实现）：最优选择。该方案完全符合面向对象设计思想：
  • 原有普通开关的switchOn()、switchOff()基础逻辑完全不变，符合单一职责原则
  • 扩展能力通过聚合方式注入，不需要修改原有开关类代码，符合开放封闭原则
  • 对外提供的getComponent()方法可支持任意数量的扩展接入，后续新增扩展不需要修改现有逻辑，灵活性极高
    所谓实体组件系统本质就是「组合优于继承」面向对象核心思想的工程化落地，完全属于面向对象编程范畴。

补充可选实现思路 #

如果不想修改原有普通开关的任何代码，还可以采用装饰器模式实现：

1. 先定义统一的开关抽象接口，包含switchOn()、switchOff两个基础方法，原有普通开关实现该接口。
2. 定时开关装饰器也实现该接口，内部持有普通开关实例，switchOn()、switchOff方法直接转发给内部普通开关，同时新增定时配置相关的自有方法。
3. switch-bag容器存储实现了开关接口的实例，需要支持定时能力的开关直接存入装饰后的实例。客户端取出实例后可通过类型判断识别扩展能力，按需调用扩展方法。
   该方案完全不侵入原有普通开关的实现，兼容性极强，也支持多扩展叠加（可以嵌套多层装饰器实现多能力组合）。

内容的提问来源于stack exchange，提问作者Robin Kreuzer