Refactoring E‑Commerce Login Using Strategy, Template, Chain‑of‑Responsibility & Decorator Patterns

Introduction

In large e‑commerce systems the login feature accumulates many variations—PC, H5, mini‑program, SMS code, username/password, SSO, third‑party, employee accounts, etc. Over time the codebase becomes fragmented with duplicated branches and scattered validation logic, making maintenance painful.

Matrix Analysis

The author applies a matrix‑thinking approach, using rows for business scenarios and columns for dimensions such as request parameters, validation rules, and processing steps. This visualisation reveals commonalities (session creation, token return) and differences (parameter sets, validation logic, business handling) that guide the design.

Strategy + Factory Refactoring

Using the classic Strategy pattern, each login scenario is encapsulated in its own strategy class. A manual factory registers these strategies and returns the appropriate instance based on request parameters, decoupling callers from concrete implementations.

Create a Spring Boot project and define a LoginStrategyEnum to list all scenarios.

Define a LoginStrategy interface and concrete strategy classes (e.g., SmsCodeLoginStrategy, UsernamePasswordLoginStrategy).

Introduce an abstract BaseLoginStrategy that implements shared steps.

Implement LoginStrategyManualFactory that maps enum values to strategy objects.

Template Method Refactoring

After isolating strategies, the Template Method pattern defines a fixed login workflow (parameter validation, business execution, result construction) while allowing subclasses to implement the variable parts.

The abstract template declares three abstract methods: validateData(), executeLogin(), and buildResult(). Concrete strategies override only the relevant steps, keeping the overall process consistent.

Chain of Responsibility for Validation

Login validation (parameter checks, blacklist, IP limits, behavior analysis) is extracted into independent handlers linked in a chain. Each handler implements doHandle() and passes control to the next node only when its check succeeds.

The chain can be assembled dynamically via SPI or annotations, allowing flexible ordering and easy addition of new validation nodes without touching existing code.

Decorator for Dynamic Enhancement

When a particular login strategy needs extra features (e.g., multi‑factor authentication, rate limiting), the Decorator pattern wraps the original strategy with a decorator that adds the new behavior while preserving the core logic.

Conclusion

By combining Strategy, Factory, Template Method, Chain of Responsibility, and Decorator patterns, the login module achieves clear responsibilities, reduced code duplication, easy extensibility, and better testability. The design adheres to the Open‑Closed Principle, supports future scenarios such as biometric or WeChat scans, and simplifies debugging and maintenance.