Conquering Complex Business Logic: A Matrix Analysis Method to Eliminate if‑else

Why if‑else Is a Problem

Relying on scattered if‑else statements to handle diverse business scenarios quickly creates tangled, hard‑to‑maintain code. The author, an Alibaba senior technical expert, illustrates this with a retail product example where three dimensions (product type, sales mode, storage mode) generate 12 combinations, leading to repetitive conditional logic.

Two Primary Refactoring Approaches

Polymorphic Extension : Leverage object‑oriented polymorphism (inheritance or composition) to encapsulate variant behavior. Example code shows a naive checkSellable(Item item) method with nested if‑else, then refactors it to a clean checkSellable(Item item) that throws an exception if the item is not sellable, relying on the runtime type to handle specifics.

Code Separation : Split business scenarios into distinct procedural methods. The article provides separate methods for normal items, combined items, and gift items, each containing its own sequence of checks before publishing.

When to Use Which?

Polymorphism is ideal when scenarios share most steps and differ only in a few actions (e.g., normal vs. combined items). Code separation works better when scenarios have largely independent workflows (e.g., gifts or clearance items).

Matrix Analysis Methodology

The author introduces a multi‑dimensional matrix analysis to decide the appropriate strategy. Rows represent business scenarios; columns represent actions or attributes. By populating the matrix, one can see which scenarios can share code and which require isolated implementations.

Examples include product‑type matrices, order‑element matrices, Boston‑style product‑growth matrices, and RFM models, demonstrating that multi‑dimensional analysis applies across product, data, and organizational contexts.

Full Methodology for Complex Business Governance

Business Understanding : Identify core entities (e.g., Item, CSPU, CombineItem) and clarify terminology.

Domain Modeling : Build clear domain models that reflect real‑world relationships, as shown in the product‑domain diagram.

Process Decomposition : Break down each business process into granular steps, forming a pyramid‑shaped hierarchy.

Multi‑Dimensional Analysis : Construct matrices to visualize scenario‑action relationships, then choose between polymorphic extension, code separation, or other patterns.

Conclusion

Controlling complexity is a core responsibility for engineers. By combining structured thinking (business understanding → domain modeling → process decomposition) with matrix‑based multi‑dimensional analysis, teams can produce clearer, more maintainable code and evolve from “if‑else coders” to “complexity conquerors.”