Implementing Coupon Grant Type Dispatch with Strategy Pattern and Map+Functional Interface in Java

The problem is to query a coupon's grant type (grantType) based on two inputs: the coupon type ( resourceType) and its identifier ( resourceId). Different coupon types (e.g., Red Packet, Shopping Coupon, QQ Membership, Takeaway Membership) are stored in separate database tables, making a simple if‑else or switch statement quickly become long and hard to maintain.

Strategy Pattern

The Strategy pattern extracts each conditional branch into its own class. By delegating the logic to concrete strategy classes (e.g., RedPaper, Shopping), the main dispatch method stays short, and modifications only affect the relevant class.

switch(resourceType){
  case "红包":
    String grantType = new Context(new RedPaper()).ContextInterface();
    break;
  case "购物券":
    String grantType = new Context(new Shopping()).ContextInterface();
    break;
  // ... other cases ...
  default:
    logger.info("查找不到该优惠券类型resourceType以及对应的派发方式");
    break;
}

While this improves maintainability, it still requires a new class for every new coupon type and does not give a clear overview of the whole dispatch logic.

Map + Functional Interface (Java 8 Lambda)

Using a Map<String, Function<String, String>> stores the condition ( resourceType) as the key and the corresponding business logic as a lambda expression (the value). This makes the dispatch table explicit and easy to read.

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

    /**
     * Initialize the dispatch logic, replacing the if‑else part.
     * key: coupon type
     * value: lambda that returns the grant type for the given resourceId
     */
    @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<String,String> result = grantTypeMap.get(resourceType);
        if (result != null) {
            return result.apply(resourceId);
        }
        return "查询不到该优惠券的发放方式";
    }
}

The actual business logic is moved to a separate service class, keeping the lambda concise.

@Service
public class GrantTypeSerive {
    public String redPaper(String resourceId) {
        // 红包的发放方式
        return "每周末9点发放";
    }
    public String shopping(String resourceId) {
        // 购物券的发放方式
        return "每周三9点发放";
    }
    public String QQVip(String resourceId) {
        // qq会员的发放方式
        return "每周一0点开始秒杀";
    }
}

A simple REST controller demonstrates how the service is invoked via HTTP.

@RestController
public class GrantTypeController {
    @Autowired
    private QueryGrantTypeService queryGrantTypeService;

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

Both approaches have trade‑offs: the Strategy pattern improves modularity but can lead to many small classes; the Map‑lambda solution is concise and gives a clear overview, but requires team members to be comfortable with Java 8 lambda syntax.