Constants的潜在缺陷
在平时的开发中都会定义一些全局变量，如单例对象、被所在类实例化对象共享的类静态变量、全局多依赖的常量等。而当一个Constants类中包含过多的常量，且依赖这个类的代码过多时，每一次修改都有以下的缺点：
- 发生修改会导致所有依赖它的类文件重新编译，花费更多的时间
- 类内包含过多的常量，变得越来越大，不利于查询某个变量
- 只需要依赖它的一小部分常量，却需要引入一整个类
在日常开发中所遇
回想起在前东家任职时，项目中确实会存在把所有的全局常量都定义在一两个类中，包括日志变量名、业务术语、表字段名、某些功能的boolean标志变量等，使得这个Constants类变得耦合与繁杂。
优化思路
- 单一职责: 将过大的Constants类根据具体功能、业务意义拆分成多个单一的类，如LoggingFieldConstants、BusinessFieldNameConstants、RedisConfigurations等
- 定义在依赖类中：如果一个常量没有被多次依赖，则可以在类中定义为成员常量，缩小范围，如集成配置类MySQLConfig、RedisConfig、HttpClientConfig等。
为什么需要Util类
- 在开发中都会遇到需要根据自己的场景执行对变量、数据进行自定义处理，如时间格式、字符切割替换、数值转换等。但是不是都需要一个特定的Util类去装载这些方法呢？
- 如果这些方法应用场景只有一处，或不能形成一个有多处依赖，能够抽象定义的方法，则在所在类定义一个处理方法来调用即可，并不需要创建过多的xxUtils类。
