您的位置：首页 > 其它

为什么接口只用于定义类型，不应该使用常量接口 ?

2017-03-12 00:12 405 查看

接口只用于定义类型，不应该使用常量接口

2014-12-10 且看且珍惜文章来源阅 1247 转 6

转藏到我的图书馆

微信分享：

《Effective Java》中说的感觉比较合理，貌似这个问题也是这里提出的，后面那篇是一开始搜到的，也有点用，反正就是不要这么使用就对了。

《Effective Java》第19条：接口只用于定义类型

当类实现接口时，接口就充当可以引用这个类的实例的类型(type)。因此，类实现了接口，就表明客户端可以对这个类的实例实施某些动作（接口中定义的方法）。为了任何其他目的而定义接口是不恰当的。
有一种接口被称为常量接口(constant interface)，它不满足上面的条件。这种接口没有包含任何方法，它只包含静态的final域，每个域都导出一个常量。使用这些常量的类实现这个接口，以避免用类名来修饰常量名。下面是一个例子：

?

1
2
3
4
5
6
7
8
9
10

// Constant interface antipattern —— do not use!

public

interface

PhysicalConstants {

// Avogadro's number (1/mol)

static

final

double

AVOGADROS_NUMBER   =

.02214199e23;

// Boltzmann constant (J/K)

static

final

double

BOLTZMANN_CONSTANT =

.3806503e-

...

常量接口模式是对接口的不良使用。类在内部使用某些常量，这纯粹是实现细节。实现常量接口，会导致把这样的实现细节泄露到该类的导出API中。类实现常量接口，这对于这个类的用户来讲并没有什么价值。实际上，这样做反而会使他们更加糊涂。更糟糕的是，它代表了一种承诺：如果在将来的发行版本中，这个类被修改了，它不再需要使用这些常量了，它依然必须实现这个接口，以确保二进制兼容性。如果非final类实现了常量接口，它的所有子类的命名空间也会被接口中的常量所“污染”。
在Java平台类库中有几个常量接口，例如

java.io.ObjectStreamConstants

。这些接口应该被认为是反面的典型，不值得效仿。
如果要导出常量，可以有几种合理的选择方案：
如果这些常量与某个现有的类或者接口紧密相关，就应该把这些常量添加到这个类或者接口中。例如，在Java平台类库中所有的数值包装类，如Integer和Double，都导出了

MIN_VALUE

和

MAX_VALUE

常量。
如果这些常量最好被看作枚举类型的成员，就应该用枚举类型(enum type)（见第30条）来导出这些常量。
否则，应该使用不可实例化的工具类(utility class)（见第4条）来导出这些常量。
下面的例子是前面的PhysicalConstants例子的工具类翻版：

?

1
2
3
4
5
6
7
8
9
10

// Constant utility class

package

com.effectivejava.science;

public

class

PhysicalConstants {

private

PhysicalConstants() { }

// Prevents instantiation

public

static

final

double

AVOGADROS_NUMBER   =

.02214199e23;

public

static

final

double

BOLTZMANN_CONSTANT =

.3806503e-

...

工具类通常要求客户端要用类名来修饰这些常量名。如果大量利用工具类导出的常量，可以通过利用静态导入(static import)机制，避免用类名来修饰常量名，不过，静态导入机制是在Java发行版本1.5中才引入的：

?

1
2
3
4
5
6
7
8
9
10

// Use of static import to avoid qualifying constants

import

static

com.effectivejava.science.PhysicalConstants.*;

public

class

Test {

double

atoms(

double

mols) {

return

AVOGADROS_NUMBER * mols;

...

// Many more uses of PhysicalConstants justify static import

简而言之，接口应该只被用来定义类型，它们不应该被用来导出常量。
=====

Java Interface（接口）是常量存放的最佳地点吗？（不是）

由于java interface中声明的字段在编译时会自动加上

static final

的修饰符，即声明为常量。因而interface通常是存放常量的最佳地点。然而在java的实际应用时却会产生一些问题。
问题的起因有两个，
第一，是我们所使用的常量并不是一成不变的，而是相对于变量不能赋值改变。
例如我们在一个工程初期定义常量

∏＝3.14

，而由于计算精度的提高我们可能会重新定义

∏＝3.14159

，此时整个项目对此常量的引用都应该做出改变。
第二，java是动态语言。
与c++之类的静态语言不同，java对一些字段的引用可以在运行期动态进行，这种灵活性是java这样的动态语言的一大优势。也就使得我们在java工程中有时部分内容的改变不用重新编译整个项目，而只需编译改变的部分重新发布就可以改变整个应用。
讲了这么多，你还不知道我要说什么吗？好，我们来看一个简单的例子：
有一个interface A，一个class B，代码如下：

?

1
2
3
4
5
6
7
8
9
10

//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，显然结果如下：

?

1	Class A's name = bright

我们现在修改A.java如下：

?

1
2
3
4

//file A.java

public

interface

A{

String name =

"bright sea"

编译A.java后重新运行B class，输入java B，注意：结果如下

?

1	Class A's name = bright

为什么不是

Class A's name = bright sea

？让我们使用jdk提供的反编译工具javap反编译B.class看个究竟，输入：javap -c B ，结果如下：

?

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Compiled from B.java

public

class

extends

java.lang.Object {

public

B();

public

static

void

main(java.lang.String[]);

Method B()

aload_0

invokespecial #

<Method java.lang.Object()>

return

Method

void

main(java.lang.String[])

getstatic #

<Field java.io.PrintStream out>

ldc #

<String

"Class A's name = bright"

  <
e868
/code>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修改如下：

?

1
2
3
4
5
6
7
8
9
10
11
12
13

//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，显然结果如下：

?

1	Class A's name = bright

现在我们修改A.java如下：

?

1
2
3
4
5
6
7

//file A.java

public

class

A{

private

static

final

String name =

"bright"

public

static

String getName(){

return

name;

我们再次编译A.java后重新运行B class，输入java B：结果如下

?

1	Class A's name = bright sea

终于得到了我们想要的结果，我们可以再次反编译B.class看看class B的改变，输入：

javap -c B

,结果如下：

?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

Compiled from B.java

public

class

extends

java.lang.Object {

public

B();

public

static

void

main(java.lang.String[]);

Method B()

aload_0

invokespecial #

<Method java.lang.Object()>

return

Method

void

main(java.lang.String[])

getstatic #

<Field java.io.PrintStream out>

new

<Class java.lang.StringBuffer>

dup

invokespecial #

<Method java.lang.StringBuffer()>

ldc #

<String

"Class A's name = "

invokevirtual #

<Method java.lang.StringBuffer append(java.lang.String)>

invokestatic #

<Method java.lang.String getName()>

invokevirtual #

<Method java.lang.StringBuffer append(java.lang.String)>

invokevirtual #

<Method java.lang.String toString()>

invokevirtual #

<Method

void

println(java.lang.String)>

return

注意标号10至15行的代码，

class B

中已经变为对

A class

的

getName()

方法的引用，当常量

name

的值改变时我们只需对

class A

中的常量做修改并重新编译，无需编译整个项目工程我们就能改变整个应用对此常量的引用，既保持了java动态优势又保持了我们使用常量的初衷，因而方法二是一个最佳解决方案。

引用地址：http://www.360doc.com/content/14/1210/17/16650130_431828218.shtml

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理

标签：

相关文章推荐

新的分享

章节导航

为什么 接口只用于定义类型，不应该使用常量接口 ?

接口只用于定义类型，不应该使用常量接口

《Effective Java》第19条：接口只用于定义类型

Java Interface（接口） 是常量存放的最佳地点吗？（不是）

为什么接口只用于定义类型，不应该使用常量接口 ?

Java Interface（接口）是常量存放的最佳地点吗？（不是）