Replacing if‑else with Strategy Pattern and Map‑Based Functional Interfaces in a Java Coupon Service

This article introduces a practical use case where a service must determine the grant type and collection rules of coupons based on two parameters: resourceType (coupon type) and resourceId (coupon code). The coupon types include Red Packet, Shopping Voucher, QQ Membership, and Delivery Membership, each stored in a different database table.

Initially, the straightforward solution is a long if‑else or switch block that selects the appropriate query logic for each resourceType . While functional, this approach leads to a very long method, poor readability, and difficult maintenance when new coupon types are added.

Strategy Pattern

The Strategy pattern extracts each conditional branch into its own class that implements a common interface. The client selects the appropriate strategy at runtime, making the code easier to extend and maintain. The article shows the classic UML structure of the pattern and provides a Java example where each coupon type (e.g., RedPaper , Shopping ) has its own strategy class.

switch(resourceType){
  case "红包":
    // query red packet grant type
    break;
  case "购物券":
    // query shopping voucher grant type
    break;
  // ... other cases
  default:
    logger.info("Cannot find grant type for resourceType");
    break;
}

Although the Strategy pattern improves maintainability, it still requires a separate class for every new coupon type, and the overall dispatch logic remains hidden behind many classes.

Map + Functional Interface

Leveraging Java 8 lambda expressions, the article proposes storing the dispatch logic in a Map<String, Function<String, String>> , where the key is the resourceType and the value is a lambda that returns the corresponding grantType . This makes the mapping explicit and easy to view.

@Service
public class QueryGrantTypeService {
    @Autowired
    private GrantTypeSerive grantTypeSerive;
    private Map
> grantTypeMap = new HashMap<>();

    /** Initialize the dispatch map, replacing the if‑else */
    @PostConstruct
    public void dispatcherInit(){
        grantTypeMap.put("红包", resourceId -> grantTypeSerive.redPaper(resourceId));
        grantTypeMap.put("购物券", resourceId -> grantTypeSerive.shopping(resourceId));
        grantTypeMap.put("qq会员", resourceId -> grantTypeSerive.QQVip(resourceId));
    }

    public String getResult(String resourceType, String resourceId){
        Function
result = grantTypeMap.get(resourceType);
        if(result != null){
            return result.apply(resourceId);
        }
        return "查询不到该优惠券的发放方式";
    }
}

@Service
class GrantTypeSerive {
    public String redPaper(String resourceId){ return "每周末9点发放"; }
    public String shopping(String resourceId){ return "每周三9点发放"; }
    public String QQVip(String resourceId){ return "每周一0点开始秒杀"; }
}

@RestController
class GrantTypeController {
    @Autowired
    private QueryGrantTypeService queryGrantTypeService;

    @PostMapping("/grantType")
    public String test(String resourceName){
        return queryGrantTypeService.getResult(resourceName, "dummyId");
    }
}

The Map‑based approach eliminates the need for many strategy classes and makes the dispatch table visible, but it requires team members to be comfortable with lambda syntax.

Conclusion

The Strategy pattern abstracts conditional logic into separate classes, improving maintainability, while the Map‑plus‑functional‑interface technique replaces the bulky if‑else with a concise, easily observable mapping, at the cost of requiring lambda proficiency.