design-patterns

BK-CI 设计模式实践

适用场景

• 需要为一段可扩展逻辑选择合适的设计模式
• 需要理解 BK-CI 里某个模式为什么这样落地
• 需要重构 if-else、分发逻辑、插件扩展点、后置处理链
• 需要判断某个能力更适合用工厂、策略、责任链、观察者还是模板方法

不适用场景

• 只是查某个类、某个接口或某段代码在哪里
• 只是普通 CRUD、简单参数封装或一次性脚本逻辑
• 问题本质是模块归属、接口设计或数据库结构，不是模式选型

快速指导

1. 先判断你解决的是哪一类问题：
   • 对象按类型创建：看 reference/1-core-patterns.md 里的工厂模式
   • 多种规则按条件切换：看策略模式
   • 多个处理步骤串联：看责任链模式
   • 状态变化后广播处理：看观察者模式
   • 固定主流程、子类只改局部：看模板方法模式
   • 在原能力外叠加附加行为：看装饰器模式
2. 在 BK-CI 里，模式选择要优先服从“模块边界 + 扩展点稳定性”，不要为了模式而模式。
3. 如果只是 2 到 3 个稳定分支，且短期不会扩展，先别急着上复杂模式。
4. 如果一段逻辑需要外部扩展、插件接入、规则分发或顺序处理，优先考虑模式，而不是继续堆 when / if-else。
5. 选型前先看项目里已有落地，不要凭空造新写法。常见实例在 reference/3-project-examples.md。

高信号规则

• 工厂模式适合“如何创建”，策略模式适合“如何选择一种行为”
• 责任链适合“多个处理器按顺序试或继续”，不适合硬凑单一判断逻辑
• 观察者适合事件解耦，不适合强事务链路里的必须同步步骤
• 模板方法适合主流程稳定、局部差异明确的场景
• 装饰器适合附加横切能力，不适合把核心流程绕得过深

关键陷阱

• 只有两个稳定分支也强行上策略或工厂，增加理解成本
• 把责任链当作“任何流程都能往里塞”的万能结构
• 观察者乱用在需要强一致性的主业务流程里
• 模式只在类图上优雅，落到 BK-CI 实际模块时却破坏分层和边界
• 只看教科书定义，不看项目里已经存在的同类实践

延伸阅读

• 核心模式：reference/1-core-patterns.md
• 选型方法：reference/2-selection-guidelines.md
• 项目案例：reference/3-project-examples.md
• 如果模式已经沉淀为通用组件：再看 utility-components
• 如果问题偏框架实践：再看 common-technical-practices