常量该如何写

概念

常量：不变的量；即计算机程序运行时，不会被程序修改的量

常量与常量值的区别

常量：形式化的表现

常量值：常量的具体和直观的表现形式

public static final String DEFAULT_PARALLELISM_KEY = "parallelism.default";

以上DEFAULT_PARALLELISM_KEY为常量；parallelism.default为常量值

理解

常量往往是在一定范围内(上下文环境中)，不可变的量；往往是一种概念分类或者通用的一定范围内的区分

比如：

• 性别分为 男 女，是一种性别概念上的分类
• 一个家庭中有两个孩子，为了区分两个孩子，第一个孩子为大宝，第二个还在为小宝，那么大宝和小宝就是这个家庭中两个孩子的区分

同样在计算机程序中，也是类似的，有的常量是全局的，如 圆周率等；

有的是某些实例具备的常量，如多个数据库的系统，每个数据库实例拥有自己的常量；

有的是某个方法(函数)具备的常量

常量该怎么写

常量不变的量，那么 final 关键字 修改 变量变成为 常量

//变量
String yes = '1';
//变量
String no = '0';
//那么 变量 变为 常量；则在变量前 添加关键字 final
final String yes = "1";
final String no = "0";

那么问题来了

final Person person = new Person("蜗牛", "男", 18);
//那么下面的代码怎么修改了person的值(将用户年龄修改为20)? 常量不是运行过程中不能修改吗
person.setAge(20);

上面是因为堆中的实例还是那个实例，没有变化的，只不过是实例中的属性发生了变化 (如家重新装修了，还是那个地址的家)

运行过程.PNG

如果上面代码更改为下面代码，则编译器就会直接报错，也是违背了常量的概念

final Person person = new Person("蜗牛", "男", 18);
//错误代码示例
person = new Person("蜗牛", "男", 20);

错误示例是因为 堆中的实例变化了，违背了常量的概念(常量值被替换了；如换了房子，家的地址就变更了)

错误运行示例.PNG

常量分类

按照作用域范围划分

1. 静态常量
2. 实例常量
3. 成员常量

class A {
    //静态成员变量属于类级别；不属于实例级别
    public static double pi = 3.14D;
    //静态常量则 在静态成员变量加上 final；
    //1.静态常量 常量表达默认使用大写 如 AAA_BBB = "aaabbb";
    public static double PI = 3.14D;
    
    //成员变量属于实例，不属于类，每次需要 new A().xxx
    public String name = "蜗牛"；
    //2.实例常量，则是在成员变量前加上 final
    public final String name1 = "蜗牛"；
        
    public void method() {
        //局部变量
        int age = 18；
        //3.局部常量则是在 局部常量前加上 final
        final int age1 = 20;
    }
}

常量类写法

常量其实不是面向对象编程的内容；在面向过程或者函数式编程中也存在常量

java中常量类通常是指 静态常量太多，需要专门的一个管理的地方；而管理常量的容器该怎么选择而已；

静态常量本质是不可变的量，又不属于面向对象内容，关键是静态常量属于类级别，所以静态常量容器不需要去创建，而是交给jvm程序启动时候管理

需要关注的问题有

• 不需要实例化
• 权限访问需要开放

常量类写法(推荐写法)

class Constants {
    //构造器私有化，控制创建
    private Constants(){
        
    }
    
    //开放权限
    public static final String CONSTANTS_1 = "1";
    public static final String CONSTANTS_2 = "2";
}

effective-java第22条中说明 接口仅用来定义类型(当类实现接口时，该接口作为一种类型，可以用来引用类的实例)，所以不要使用 接口管理所有的常量；正常接口可以有常量，如果仅仅用接口(接口不做类型使用，没有契约方法)管理常量，是不推荐的；

不推荐使用接口管理常量原因
-常量泄漏到类的导出API中(类在内部使用常量，属于实现细节)
-如果类实现常量，那么是没有意义的，因为常量接口是没有契约方法的