java接口入门_Java入门接口

java接口入门

Java接口有两种主要的命名约定：

1. 没有前缀或后缀的接口， ~Impl后缀的实现
2. ~I对接口的前缀，但对于实现无前缀或后缀。

后者在来自其他语言（例如C＃，C ++或Python）的人们中很受欢迎。 让我向您展示，在Java生态系统中，前一个约定比后者更强大。

接口命名约定的主要好处之一是，它可以帮助您对接口进行编码而不是对实现进行编码（这是一种很好的编码做法）。

举个例子，让我们看一下第二种约定编写的以下代码摘录。

INotifier notifier = myFactory.getNotifier();// ...
Scheduler scheduler = ASingleton.getInstance().getScheduler();
// ...
IBrowser browser = loadBrowser();

我们可以发现Scheduler没有~I前缀。 这可能引起我们不小心将代码编码到实现上的担忧（结果是调用了一些接口中不存在的调度程序变量的方法，形成了不灵活的代码）。

然而，这种命名约定有可能是缺乏的另一个显而易见的原因~I前缀：调度可能只是一个普通班，并没有定义的接口。

让我们看看使用第一个命名约定时这段代码的样子：

Notifier notifier = myFactory.getNotifier();// ...
SchedulerImpl scheduler = ASingleton.getInstance().getScheduler();
// ...
Browser browser = loadBrowser();

我们立即发现令人反感的~Impl后缀，因为更容易发现存在（和不同）的内容而不是缺少的内容（ ~I ）。

毫无疑问，Scheduler接口是否存在。 当~Impl后缀在类定义，工厂或测试之外的其他地方被发现时，在Java代码中充当后缀，类似于IDE中的警告。 这是首选第一个命名约定¹的第一个也是主要原因。

第二个原因较少，但仍然很重要。 在C＃中，所有标准库都使用~I前缀作为接口，因此遵循相同约定的用户类自然适合。

但是，在Java（及其类似Spring的大型框架）中，所有接口的命名都没有前缀： List<T> ，而不是IList； Serializable ，不可ISerializable； ApplicationContext ，而不是IApplicationContext。

与语言生态系统所使用的命名约定一起使用是一种很好的风格。

因此，命名不只是个人风格的偏爱， 它具有真正的好处，可以减少代码中的错误数量，并使其在语言生态系统中更具可读性。

[1]如今，对于局部变量，通常使用类型推断来推导类型。 但是，该原理对于所有其他用法仍然有效：字段（类成员）以及构造函数和函数参数。

翻译自: https://hackernoon.com/naming-interfaces-in-java-itr3qet

java接口入门