关于使用interface来定义常量 about p3c HOT 5 CLOSED

不去实现这个接口那就没有这问题了吧

from p3c.

@chenxuyuan2016 对，不实现当然没问题，我的问题是该不该这样使用

from p3c.

@Tneciv interface和@interface中定义的常量，是自带public static final 修饰的，其实和正常的class public static final 是一致的，我个人觉得正确的使用它和正常的常量类是一致的，而且感觉会少些代码何乐而不为呢。该不该使用它并不是由规范来决定的，是看个人的想法，如果你觉得这样做不安全可以不实用，如果你觉得这样做方便并且能够让他安全使用，不必去纠结。

from p3c.

@chenxuyuan2016 是应该结合使用场景选择，既然说到这里了就顺便引用下我之前看到一篇文章里写到的优缺点，来自反模式的接口常量

从直观的感受，接口写起来方便多了。
因为类中写的字符比接口多，所以编译之后文件大小也是类文件比接口文件大。
在JVM加载过程中，接口没有类提供的额外特种（如重载、方法的动态绑定等），所以接口加载比类快。

接口是不能阻止被实现或继承的，也就是说子接口或实现中是能够覆盖掉常量的定义，这样通过父、子接口(或实现) 去引用常量是可能不一致的；
同样的，由于被实现或继承，造成在继承树中可以用大量的接口、类或实例去引用同一个常量，从而造成接口中定义的常量污染了命名空间；
接口暗含的意思是：它是需被实现的，代表着一种类型，它的公有成员是要被暴露的API，但是在接口中定义的常量还算不上API。

from p3c.

@Tneciv 之前是顺从Idea的Icons模式来开发的https://www.jetbrains.org/intellij/sdk/docs/reference_guide/work_with_icons_and_images.html，所以在其他地方可能也有这种定义。
@chenxuyuan2016 用接口确实要方便很多，不过既然我们是Java代码规约插件，也应该尽量遵从权威的开发模式，所以在下一个版本会修改为在类中定义或者是kotlin的object定义

感谢大家的意见

from p3c.