技术需求:
最近在多个项目中用到了一些常量值,在使用过程中也看了一下其他人的代码,然后发现了一些有意思的东西。简单的一个常量,是有三种声明方式的,但在看过各个项目中后,感觉某些人对这方面认识的很模糊,几乎就是瞎用的。那么,这三种声明方式,在什么情况下使用哪一种呢???
然后我上网查了大量资料,整理了一下。欢迎大佬指点!
技术实例:
首先让我们认识一下这三种方式:常量类、常量接口、枚举。
1、常量类方式。
常量类方式,顾名思义就是在一个类中声明出这些常量。
public final class VehicleConstant{
private VehicleConstant() {}
public static final String VCL_BRAND = "品牌";
public static final String VEL_TYPE = "机型";
public static final String VCL_KIND = "机种";
}
此处定义成final且定义一个private的构造方法,是为了不让其他类继承,禁止实例化此类,调用时直接以"类.常量"的方式调用。
2、常量接口方式。
常量接口方式,就是把常量声明到接口里。如下:
public interface VehicleConstant{
String VCL_BRAND = "品牌";
String VEL_TYPE = "机型";
String VCL_KIND = "机种";
}
接口中定义的"变量",其实就是常量,接口中的"变量"默认都是 "public static final"类型,即为常量,因此接口可以省略"public static final"而直接写成 “type variable”。
3、枚举方式。
枚举方式。就是把常量声明到枚举里。如下:
public enum VehicleConstant{
private VehicleConstant(String value){ this.value = value; }
VCL_BRAND("1","品牌");
VEL_TYPE("2","机型");
VCL_KIND("3","机种");
private String code;
private String value;
//此处省略code和value的get、set方法
}
技术分析:
1、在上面的实例中,我们可以看出,第一种和第二种比较相似,只是第二种中减少了“public static final”,而且这两种都可以通过“类名.常量”的方式访问。看似第二种更加方便,但让我们看一下本质:
1.1、首先,让我来看一下接口和类的定义。
类:把事物的特征和行为定义在一起,这个概念和语法就是类;
接口:让规范和实现相分离;接口只是一个规范,不再是一个有具体功能的类;
常量作为一个具体的值,应该算是事物的特性。在这方面看来使用接口不太合适。
《Effective Java》第19条:接口只用于定义类型。
当类实现接口时,接口就充当可以引用这个类的实例的类型(type)。因此,类实现了接口,就表明客户端可以对这个类的实例实施某些动作(接口中定义的方法)。为了任何其他目的而定义接口是不恰当的。
有一种接口被称为常量接口(constant interface),它不满足上面的条件。这种接口没有包含任何方法,它只包含静态的final域,每个域都导出一个常量。
常量接口模式是对接口的不良使用。类在内部使用某些常量,这纯粹是实现细节。实现常量接口,会导致把这样的实现细节泄露到该类的导出API中。类实现常量接口,这对于这个类的用户来讲并没有什么价值。实际上,这样做反而会使他们更加糊涂。更糟糕的是,它代表了一种承诺:如果在将来的发行版本中,这个类被修改了,它不再需要使用这些常量了,它依然必须实现这个接口,以确保二进制兼容性。如果非final类实现了常量接口,它的所有子类的命名空间也会被接口中的常量所“污染”。
在Java平台类库中有几个常量接口,例如java.io.ObjectStreamConstants。这些接口应该被认为是反面的典型,不值得效仿。
1.2、再从java机制上说一下这两种方法。
在interface和class中定义相同的常量,interface生成的class文件比class生成的class文件会更小,而且更简洁、效率更高。
反转。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
由于java interface中声明的字段在编译时会自动加上static final的修饰符,即声明为常量。因而interface通常是存放常量的最佳地点。然而在java的实际应用时却会产生一些问题。
问题的起因有两个,
第一,是我们所使用的常量并不是一成不变的,而是相对于变量不能赋值改变。
例如我们在一个工程初期定义常量∏=3.14,而由于计算精度的提高我们可能会重新定义∏=3.14159,此时整个项目对此常量的引用都应该做出改变。
第二,java是动态语言。
与c++之类的静态语言不同,java对一些字段的引用可以在运行期动态进行,这种灵活性是java这样的动态语言的一大优势。也就使得我们在java工程中有时部分内容的改变不用重新编译整个项目,而只需编译改变的部分重新发布就可以改变整个应用。
讲了这么多,你还不知道我要说什么吗?好,我们来看一个简单的例子:
有一个interface A,一个class B,代码如下:
//file A.java
public interface A {
String name = "bright";
}
//file B.java
public class B {
public static void main(String[] args) {
System.out.println("Class A's name = " + A.name);
}
}
够简单吧,好,编译A.java和B.java。
运行,输入java B,显然结果如下:
Class A's name = bright
我们现在修改A.java如下:
//file A.java
public interface A{
String name = "bright sea";
}
编译A.java后重新运行B class,输入java B,注意:结果如下
Class A's name = bright
为什么不是Class A’s name = bright sea?让我们使用jdk提供的反编译工具javap反编译B.class看个究竟,输入:javap -c B ,结果如下:
Compiled from B.java
public class B extends java.lang.Object {
public B();
public static void main(java.lang.String[]);
}
Method B()
0 aload_0
1 invokespecial #1 <Method java.lang.Object()>
4 return
Method void main(java.lang.String[])
0 getstatic #2 <Field java.io.PrintStream out>
3 ldc #3 <String "Class A's name = bright">
5 invokevirtual #4 <Method void println(java.lang.String)>
8 return
注意到标号3的代码了吗?由于引用了一个static final的字段,编译器已经将interface A中name的内容编译进了class B中,而不是对interface A中的name的引用。因此除非我们重新编译class B,interface A中name发生的变化无法在class B中反映。如果这样去做那么java的动态优势就消失殆尽。
解决方案,有两种解决方法。
第一种方法是不再使用常量,将所需字段放入class中声明,并去掉final修饰符。但这种方法存在一定的风险,由于不再是常量着因而在系统运行时有可能被其他类修改其值而发生错误,也就违背了我们设置它为常量的初衷,因而不推荐使用。
第二种方法,将常量放入class中声明,使用class方法来得到此常量的值。为了保持对此常量引用的简单性,我们可以使用一个静态方法。我们将A.java和B.java修改如下:
//file A.java
public class A {
private static final String name = "bright";
public static String getName() {
return name;
}
}
//file B.java
public class B {
public static void main(String[] args) {
System.out.println("Class A's name = " + A.getName());
}
}
同样我们编译A.java和B.java。运行class B,输入java B,显然结果如下:
Class A's name = bright
现在我们修改A.java如下:
//file A.java
public class A{
private static final String name = "bright";
public static String getName(){
return name;
}
}
我们再次编译A.java后重新运行B class,输入java B:结果如下
Class A's name = bright sea
终于得到了我们想要的结果,我们可以再次反编译B.class看看class B的改变,输入:
javap -c B,结果如下:
Compiled from B.java
public class B extends java.lang.Object {
public B();
public static void main(java.lang.String[]);
}
Method B()
0 aload_0
1 invokespecial #1 <Method java.lang.Object()>
4 return
Method void main(java.lang.String[])
0 getstatic #2 <Field java.io.PrintStream out>
3 new #3 <Class java.lang.StringBuffer>
6 dup
7 invokespecial #4 <Method java.lang.StringBuffer()>
10 ldc #5 <String "Class A's name = ">
12 invokevirtual #6 <Method java.lang.StringBuffer append(java.lang.String)>
15 invokestatic #7 <Method java.lang.String getName()>
18 invokevirtual #6 <Method java.lang.StringBuffer append(java.lang.String)>
21 invokevirtual #8 <Method java.lang.String toString()>
24 invokevirtual #9 <Method void println(java.lang.String)>
27 return
注意标号10至15行的代码,class B中已经变为对A class的getName()方法的引用,当常量name的值改变时我们只需对class A中的常量做修改并重新编译,无需编译整个项目工程我们就能改变整个应用对此常量的引用,既保持了java动态优势又保持了我们使用常量的初衷,因而方法二是一个最佳解决方案。
此处参考了:接口只用于定义类型,不应该使用常量接口
2、上面分析了第一种以及第二种方法,下面说一下第三种的枚举方式。
枚举的优势显而易见,在定义了常量同事又加入了备注,可以清晰的认识得到该常量的含义,尤其大大方便了维护的成本。
分析结果:
总的来看,这三种方式各有利弊,但主要还是看业务的需求了。
可能也跟每个程序员的使用习惯有关系,但个人建议:枚举>常量类>常量接口(尽量不适应)
最后奉上一句话:技术有很多种,最适合业务需求的才是最正确的!!!