是否应使用 public 访问修饰符声明Java接口中的方法?
public
当然,技术上并不重要 . 实现 interface 的类方法始终为 public . 但什么是更好的惯例?
interface
Java本身并不一致 . 例如,请参阅 Collection 与 Comparable ,或 Future 与 ScriptEngine .
Collection
Comparable
Future
ScriptEngine
人们将从IDE或Javadoc中的代码完成中学习您的界面,而不是从阅读源 . 所以把“公共”放在源头是没有意义的 - 没有人在阅读消息来源 .
如果没有接口,我总是写下我会使用的东西,我正在编写一个直接实现,即我会使用 public .
我使用了_f5790_修饰符的declare方法,因为它使代码更具可读性,特别是在语法高亮的情况下 . 在我们的最新项目中,我们使用了Checkstyle,它在接口方法上显示了带有 public 修饰符的默认配置的警告,所以我切换到省略它们 .
所以我'm not really sure what'最好,但我真的不喜欢的一件事是在接口方法上使用 public abstract . Eclipse在使用"Extract Interface"进行重构时有时会这样做 .
public abstract
这完全是主观的 . 我省略了多余的 public 修饰符,因为它看起来像杂乱 . 正如其他人所说 - 一致性是决定的关键 .
值得注意的是,C#语言设计者决定强制执行此操作 . Declaring an interface method as public in C# is actually a compile error. 虽然一致性在语言中可能并不重要,所以我猜这与Java并不直接相关 .
Java接口中应省略public修饰符(在我看来) .
由于它不会添加任何额外信息,因此只会引起人们对重要内容的注意 .
大多数样式指南都会建议您将其遗漏,但当然,最重要的是在整个代码库中保持一致,特别是对于每个界面 . 下面的例子很容易让一些不熟悉Java的人感到困惑:
public interface Foo{ public void MakeFoo(); void PerformBar(); }
JLS清楚地说明了这一点:
允许但不鼓励作为样式,为接口中声明的方法冗余地指定公共和/或抽象修饰符 .
随着Java 8/9中接口方法的 private , static , default 修饰符的引入,事情变得更加复杂,我倾向于认为完整的声明更具可读性(需要Java 9才能编译):
private
static
default
public interface MyInterface { //minimal int CONST00 = 0; void method00(); static void method01() {} default void method02() {} private static void method03() {} private void method04() {} //full public static final int CONST10 = 0; public abstract void method10(); public static void method11() {} public default void method12() {} private static void method13() {} private void method14() {} }
我会避免使用默认应用的修饰符 . 正如所指出的,它可能导致不一致和混乱 .
我看到的最糟糕的是一个声明为 abstract 的方法的接口...
abstract
接口中的方法默认为public和abstract的原因对我来说似乎很合乎逻辑 .
接口中的方法默认情况下是抽象的,以强制实现类提供实现,并且默认情况下是公共的,因此实现类可以访问它 .
在代码中添加这些修饰符是多余的,无用的,只能导致您缺乏对Java基础知识的了解和/或理解 .
我更喜欢跳过它,我在某处读取了默认接口, public 和 abstract .
令我惊讶的是,这本书--Head First Design Patterns,正在使用带有接口声明和界面方法的 public ...这让我再次重新思考,我登上了这篇文章 .
无论如何,我认为应该忽略冗余信息 .
尽管很久以前就已经提出了这个问题,但我觉得全面的描述会澄清为什么在接口常量之前不需要在方法和公共静态最终之前使用公共抽象 .
首先,接口用于为一组不相关的类指定常用方法,每个类都有一个独特的实现 . 因此,无法将访问修饰符指定为私有,因为要覆盖的其他类无法访问它 .
其次,虽然可以启动接口类型的对象,但接口是由实现它的类实现的,而不是继承的 . 并且由于接口可能由不在同一个包中的不同无关类实现(实现),因此受保护的访问修饰符也是无效的 . 因此,对于访问修饰符,我们只剩下公共选择 .
第三,接口没有任何数据实现,包括实例变量和方法 . 如果存在在接口中插入已实现的方法或实例变量的逻辑原因,那么它必须是继承层次结构中的超类而不是接口 . 考虑到这一事实,由于无法在接口中实现任何方法,因此接口中的所有方法都必须是抽象的 .
第四,接口只能包含常量作为其数据成员,这意味着它们必须是最终的,当然最终的常量被声明为静态,只保留它们的一个实例 . 因此,静态final也是接口常量必须的 .
因此总的来说,尽管在方法和公共静态最终在接口的常量之前使用公共抽象是有效的但是因为没有其他选项,所以它被认为是冗余的而不是使用的 .
11 回答
人们将从IDE或Javadoc中的代码完成中学习您的界面,而不是从阅读源 . 所以把“公共”放在源头是没有意义的 - 没有人在阅读消息来源 .
如果没有接口,我总是写下我会使用的东西,我正在编写一个直接实现,即我会使用
public
.我使用了_f5790_修饰符的declare方法,因为它使代码更具可读性,特别是在语法高亮的情况下 . 在我们的最新项目中,我们使用了Checkstyle,它在接口方法上显示了带有
public
修饰符的默认配置的警告,所以我切换到省略它们 .所以我'm not really sure what'最好,但我真的不喜欢的一件事是在接口方法上使用
public abstract
. Eclipse在使用"Extract Interface"进行重构时有时会这样做 .这完全是主观的 . 我省略了多余的
public
修饰符,因为它看起来像杂乱 . 正如其他人所说 - 一致性是决定的关键 .值得注意的是,C#语言设计者决定强制执行此操作 . Declaring an interface method as public in C# is actually a compile error. 虽然一致性在语言中可能并不重要,所以我猜这与Java并不直接相关 .
Java接口中应省略public修饰符(在我看来) .
由于它不会添加任何额外信息,因此只会引起人们对重要内容的注意 .
大多数样式指南都会建议您将其遗漏,但当然,最重要的是在整个代码库中保持一致,特别是对于每个界面 . 下面的例子很容易让一些不熟悉Java的人感到困惑:
JLS清楚地说明了这一点:
随着Java 8/9中接口方法的
private
,static
,default
修饰符的引入,事情变得更加复杂,我倾向于认为完整的声明更具可读性(需要Java 9才能编译):我会避免使用默认应用的修饰符 . 正如所指出的,它可能导致不一致和混乱 .
我看到的最糟糕的是一个声明为
abstract
的方法的接口...接口中的方法默认为public和abstract的原因对我来说似乎很合乎逻辑 .
接口中的方法默认情况下是抽象的,以强制实现类提供实现,并且默认情况下是公共的,因此实现类可以访问它 .
在代码中添加这些修饰符是多余的,无用的,只能导致您缺乏对Java基础知识的了解和/或理解 .
我更喜欢跳过它,我在某处读取了默认接口,
public
和abstract
.令我惊讶的是,这本书--Head First Design Patterns,正在使用带有接口声明和界面方法的
public
...这让我再次重新思考,我登上了这篇文章 .无论如何,我认为应该忽略冗余信息 .
尽管很久以前就已经提出了这个问题,但我觉得全面的描述会澄清为什么在接口常量之前不需要在方法和公共静态最终之前使用公共抽象 .
首先,接口用于为一组不相关的类指定常用方法,每个类都有一个独特的实现 . 因此,无法将访问修饰符指定为私有,因为要覆盖的其他类无法访问它 .
其次,虽然可以启动接口类型的对象,但接口是由实现它的类实现的,而不是继承的 . 并且由于接口可能由不在同一个包中的不同无关类实现(实现),因此受保护的访问修饰符也是无效的 . 因此,对于访问修饰符,我们只剩下公共选择 .
第三,接口没有任何数据实现,包括实例变量和方法 . 如果存在在接口中插入已实现的方法或实例变量的逻辑原因,那么它必须是继承层次结构中的超类而不是接口 . 考虑到这一事实,由于无法在接口中实现任何方法,因此接口中的所有方法都必须是抽象的 .
第四,接口只能包含常量作为其数据成员,这意味着它们必须是最终的,当然最终的常量被声明为静态,只保留它们的一个实例 . 因此,静态final也是接口常量必须的 .
因此总的来说,尽管在方法和公共静态最终在接口的常量之前使用公共抽象是有效的但是因为没有其他选项,所以它被认为是冗余的而不是使用的 .