前言

这几年内参与了很多系统的开发，有B端，也有C端，有QPS1都难以保证的，也有QPS日常几十万的，从而也就接触了各式各类的代码风格。

这些代码中，最常见的一个坏习惯，就是特别喜欢定义一个笼统的常量类，然后不断地往里边堆积内容，后期变得十分混乱。其实有部分常量，是可以定义成一个枚举，后续维护起来，会清晰很多。

案例

我们很多业务，经常是有各种选项，每个选项对应不同的业务逻辑，就像前端的一个单选框一样。

例如某个业务，是白名单的才能使用，黑名单的不能使用，这个时候，我们就遇到了一些和常量相关的东西了。

常见的开发方案，是通过一个字段userType，来标识用户的身份，如1为白名单，0为黑名单。

1.定义常量类

针对上述的userType类型，定义2个常量，用于后续的变量判断中。

package com.example.springbootconstant.constant;

/**
 * @author hongcunlin
 */
public class UserConstant {
    /**
     * 黑名单
     */
    public static final Integer USER_TYPE_BLACK = 0;

    /**
     * 白名单
     */
    public static final Integer USER_TYPE_WHITE = 1;
}

2.编写服务

我们的一些服务，只有白名单才能使用，其他人是无法使用的，于是有了如下的接口

package com.example.springbootconstant.service;

/**
 * 用户服务
 *
 * @author hongcunlin
 */
public interface UserService {
    /**
     * 娱乐
     *
     * @param userType 用户类型
     * @return 娱乐结果
     */
    String play(Integer userType);
}

以及上述接口的实现

package com.example.springbootconstant.service.impl;

import com.example.springbootconstant.constant.UserConstant;
import com.example.springbootconstant.service.UserService;
import org.springframework.stereotype.Service;

/**
 * 用户服务
 *
 * @author hongcunlin
 */
@Service
public class UserServiceImpl implements UserService {
    @Override
    public String play(Integer userType) {
        // 只有白名单才能进入
        if (UserConstant.USER_TYPE_WHITE.equals(userType)) {
            return "OK";
        }
        return "NO";
    }
}

这里重点来了，很多人就是喜欢这样的写法，其实还可以接受，毕竟没有使用魔法常量，即没有提取常量，直接硬编码到业务逻辑中。

但是这样的代码，还是有提升空间的，就是将常量类改造为一个枚举类。

优化

不同于定义一个常量类，我们针对用户类型，定义一个枚举，后续新增的用户类型，都可以在这里添加。

package com.example.springbootconstant.enums;

import lombok.AllArgsConstructor;
import lombok.Getter;
import lombok.NoArgsConstructor;

/**
 * 用户类型枚举
 *
 * @author hongcunlin
 */
@Getter
@NoArgsConstructor
@AllArgsConstructor
public enum UserTypeEnum {
    /**
     * 黑名单
     */
    BLACK(0, "黑名单"),

    /**
     * 白名单
     */
    WHITE(1, "白名单");

    /**
     * 用户类型值
     */
    private Integer value;

    /**
     * 用户类型说明
     */
    private String desc;
}

而其他业务相关的常量，则另外新起枚举或类，这样就可以将业务归类处理了，维护起来也十分清晰。

2.编写服务

这里照旧和传统写一样，定义了一个接口

package com.example.springbootconstant.service;

/**
 * 用户服务
 *
 * @author hongcunlin
 */
public interface UserService {
    /**
     * 娱乐
     *
     * @param userType 用户类型
     * @return 娱乐结果
     */
    String play(Integer userType);
}

只是实现的内容，我们通过枚举来进行内容比较。

package com.example.springbootconstant.service.impl;

import com.example.springbootconstant.constant.UserConstant;
import com.example.springbootconstant.enums.UserTypeEnum;
import com.example.springbootconstant.service.UserService;
import org.springframework.stereotype.Service;

/**
 * 用户服务
 *
 * @author hongcunlin
 */
@Service
public class UserServiceImpl implements UserService {
    @Override
    public String play(Integer userType) {
        // 只有白名单才能进入
//        if (UserConstant.USER_TYPE_WHITE.equals(userType)) {
        if (UserTypeEnum.WHITE.getValue().equals(userType)) {
            return "OK";
        }
        return "NO";
    }
}

逻辑显然比传统写法清晰了很多。

最后

本文通过一个很简单的例子，说明了项目开发中一个常见的不良习惯，以及对应的优化方案，虽然简单，但是问题十分泛滥，所以有必要提一下。后续笔者有空，将分享更多相关的内容。