Mastering Complex Business Logic: Matrix Analysis & Polymorphic Design

When business scenarios differ, developers often default to extensive if‑else statements, which quickly become hard to maintain. To eliminate these, the article introduces a multidimensional analysis method—matrix analysis—and discusses how to think about and analyze complex business logic.

From if‑else to Better Practices

Using the example of retail product handling, the article shows that differences in product type, sales mode, and storage lead to 2 × 3 × 2 = 12 possible combinations, which explains the proliferation of nested if‑else code.

Two Approaches to Reduce if‑else

Polymorphic Extension: leverage object‑oriented polymorphism for code reuse and extensibility.

Code Separation: isolate scenario‑specific logic into separate procedural code blocks.

Polymorphic Extension

Polymorphism can be implemented via inheritance or composition (similar to the Strategy pattern). An example using inheritance:

public void checkSellable(Item item) {
    if (item.isNormal()) {
        item.isSellable(); // omitted exception handling
    } else {
        List<Item> childItems = getChildItems();
        childItems.forEach(childItem -> childItem.isSellable()); // omitted exception handling
    }
}

This implementation violates the Open‑Closed Principle and lacks explicit business semantics. A refined version makes the relationship explicit and uses polymorphism:

public void checkSellable(Item item) {
    if (!item.isSellable()) {
        throw new BizException("商品的状态不可售，不能上架");
    }
}

Code Separation

Code separation keeps different scenarios in distinct methods, improving clarity but reducing reuse:

/** 1. 普通商品上架 */
public void itemOnSale() {
    checkItemStock(); // 检查库存
    checkItemSellable(); // 检查可售状态
    checkItemPurchaseLimit(); // 检查限购
    checkItemFreight(); // 检查运费
    checkItemCommission(); // 检查佣金
    checkItemActivityConflict(); // 检查活动冲突
    generateCspuGroupNo(); // 生成单品组号
    publishItem(); // 发布商品
}

/** 2. 组合商品上架 */
public void combineItemOnSale() {
    checkCombineItemStock();
    checkCombineItemSellable();
    checkCombineItemPurchaseLimit();
    checkCombineItemFreight();
    checkCombineItemCommission();
    checkCombineItemActivityConflict();
    generateCspuGroupNo();
    publishCombineItem();
}

/** 3. 赠品上架 */
public void giftItemOnSale() {
    checkGiftItemSellable();
    publishGiftItem();
}

While clear, this approach suffers from limited reuse.

When to Use Polymorphism vs. Code Separation

If only a single method differs between scenarios (e.g., checkSellable()), polymorphic inheritance is preferable. If the entire workflow differs (as with gift items), separate code paths are clearer.

Matrix Analysis Methodology

The core of the article is the matrix analysis method. By constructing a matrix where rows represent business scenarios and columns represent actions, teams can visualize differences and decide the optimal implementation strategy.

Example product matrix (scenario vs. action) reveals that normal and combined items can share the same process, while gifts and clearance items require distinct flows.

Other Matrix Applications

Boston matrix for product forecasting, order element matrix for transaction scenarios, and correlation matrices for data analysis are also discussed, illustrating the broad applicability of multidimensional thinking.

Comprehensive Methodology

The complete workflow consists of four stages:

Business Understanding – identify core concepts and processes.

Domain Modeling – abstract entities and relationships.

Process Decomposition – break down workflows using structured, top‑down then bottom‑up analysis.

Multidimensional Analysis – apply matrix thinking to capture scenario‑action dependencies and guide implementation choices.

Applying this methodology helps engineers move from "if‑else coder" to "complexity conqueror".

By combining structured thinking with matrix analysis, teams can achieve clearer, more maintainable designs for complex business systems.