design-patterns

BK-CI Design Pattern Practice

Applicable Scenarios

Need to choose a suitable design pattern for a piece of extensible logic
Need to understand why a certain pattern in BK-CI is implemented this way
Need to refactor if-else, dispatch logic, plugin extension points, post-processing chains
Need to determine whether a certain capability is better suited to Factory, Strategy, Chain of Responsibility, Observer, or Template Method

Just looking up where a certain class, interface, or piece of code is
Just ordinary CRUD, simple parameter encapsulation, or one-off script logic
The essence of the problem is module ownership, interface design, or database structure, not pattern selection

First determine which type of problem you are solving:
- Objects created by type: see reference/1-core-patterns.md the Factory pattern in
- Multiple rules switched by condition: see the Strategy pattern
- Multiple processing steps chained in sequence: see the Chain of Responsibility pattern
- Broadcast processing after a state change: see the Observer pattern
- Fixed main flow with subclasses changing only parts: see the Template Method pattern
- Adding additional behavior on top of existing capabilities: see the Decorator pattern
In BK-CI, pattern selection should first obey "module boundaries + extension point stability"; do not use patterns for the sake of patterns.
If there are only 2 to 3 stable branches and no expansion in the short term, do not rush to adopt complex patterns.
If a piece of logic needs external extension, plugin integration, rule dispatch, or sequential processing, prioritize patterns instead of continuing to pile up when / if-else。
Before selecting, first look at existing implementations in the project; do not invent new approaches out of thin air. Common examples are in reference/3-project-examples.md。

The Factory pattern suits "how to create"; the Strategy pattern suits "how to choose one behavior"
Chain of Responsibility suits "multiple handlers trying in order or continuing"; it does not suit forcing a single judgment logic
Observer suits event decoupling; it does not suit mandatory synchronous steps in a strong transaction chain
Template Method suits scenarios where the main flow is stable and local differences are clear
Decorator suits adding cross-cutting capabilities; it does not suit wrapping the core flow too deeply

Forcing Strategy or Factory even when there are only two stable branches, increasing comprehension cost
Treating Chain of Responsibility as a universal structure into which "any process can be stuffed"
Misusing Observer in main business processes that require strong consistency
The pattern is elegant only on the class diagram, but when it lands in actual BK-CI modules it breaks layering and boundaries
Only looking at textbook definitions and not at similar practices that already exist in the project