正如我们在Java8接口方法中为什么不允许“同步”的原因是什么？而为什么是“最终”不能在Java中8接口中的方法允许吗？，扩展接口以定义行为比它初看起来要微妙得多。事实证明，每种可能的修饰语都有各自的故事。这不仅仅是盲目地复制类的工作方式。（这至少在事后看来是显而易见的，因为面向单继承的面向对象建模工具不会自动用于多继承。）
让我们从一个显而易见的答案开始：接口 一直 被限制为仅具有公共成员，并且尽管我们在Java
8中向接口添加了默认方法和静态方法，但这并不意味着我们必须更改所有内容以使其“更像”类。
与with
synchronized和相比
final，它本来是支持默认方法的严重错误，但较弱的可访问性（尤其是私有的）是要考虑的合理功能。私有接口方法，无论是静态的还是实例的（请注意，由于它们不参与继承，因此它们不是默认值）是一种非常明智的工具（尽管非公共帮助程序类可以轻松地模拟它们）。
实际上，我们确实考虑过在Java
8中使用私有接口方法。由于资源和时间的限制，多数情况下，这些只是从列表的底部跌落而已。此功能很有可能会在某天重新出现在待办事项列表中。（更新：接口中的私有方法已在Java
9中添加。）
打包和受保护的方法比看起来复杂得多。多重继承的复杂性和的真实含义的复杂性
protected会以各种不那么有趣的方式相互作用。所以我不会为此屏住呼吸。
因此，简短的答案是，私有接口方法是我们可以在8中完成的事情，但是我们不能做所有可以完成但仍可以发货的事情，因此它被削减了，但可能会回来。
