在应用程序中，我们经常需要一个常量文件来存储被多个地方引用的共享常量。在设计一个应用的时候，我也遇到过类似的情况，很多地方都需要各种常量。我确定需要一个单独的文件来存储这些静态公共常量。但是我不是特别确定是使用接口还是类（枚举不能满足我的需求）。我有两个选择：使用如下界面：12345包一；公共接口常量{StringNAME="name1";intMAX_VAL=25;}或12345包二；公共类常量{publicstaticfinalStringNAME="name1";publicstaticfinalintMAX_VAL=25；我的观点是使用接口。因为接口会自动将成员变量设置为静态（static）、不可变（final），这样可以防止某些情况下误加新常量。这也让代码看起来更简洁明了。同时简单测试发现，同一个接口（字节码文件）占用209字节（在ubuntu14.04机器上），而类（字节码文件）占用366字节（也是操作系统）。更少的字节码文件意味着更少的加载和维护成本。另外，JVM在加载接口时，不需要担心类提供的额外特性（如重载、方法的动态绑定等），所以加载速度更快。这看起来非常好，但它是经典反模式的一个例子。虽然使用接口来保存常量似乎很有用，但它为以后对应用程序的扩展留下了漏洞。假设存在一个密切依赖于这些常量的类。开发人员通过接口用对常量的引用填充类。如：1packagename.Constant.CONSTANT_NAME所以，为了“清理”这段代码，他可能想实现接口，这样他就不需要到处写“packagename.Constants”，所有的常量都可以直接访问。但是，一旦他实现了接口，所有的常量就变成了“契约”的一部分（因为所有的常量都是公共的，静态的）。这导致向类中添加了不必要的常量。这动摇了整个基础并造成混乱。在Java中没有办法阻止类实现接口。另一种方式，我们可以将类设置为最终类，这样它就不能被扩展。甚至，我们可以将构造函数设为私有，以防止此类被实例化，这样契约就永远不会被破坏。此外，如果在同一类中多次使用特定常量，开发人员可以使用静态导入。对于常量类，比较好的设计应该是：1234567包三；//通过添加final使类不可扩展添加final关键字避免继承publicfinalclassConstants{//隐藏构造函数HiddenconstructorprivateConstants(){}publicstaticStringNAME="name";}静态导入的例子：123456importstaticthree.Constants.NAME;publicclassUseConstants{publicstaticvoidmain(String[]args){System.out.println("常量的值为"+NAME);这个设计问题也被称为常量接口反模式。原文链接：dzone翻译：ImportNew.com-paddx翻译链接：http://www.importnew.com/16700.html
