Question

我有一个接口，其实现者在内部都需要一个公共方法 - 它不需要是公共接口的一部分。此外，管道中还有将来需要此功能的接口。

让这个接口实现一个只有这个默认方法实现的不同接口才是好的设计？这样，所有实现者都可以无缝地访问公共方法。但是，由于没有“私有默认”方法的概念，该方法也暴露给客户，我觉得这是不对的。

为此采用单独的具体工具类更好的方法吗？或者使用所需方法创建我的接口的抽象实现，并让客户端扩展它？

编辑：我的问题更倾向于找出一个只有默认方法的界面是否合理，设计明智？在接口中使用静态方法实际上似乎没有争用。

Answer 1

接口用于隔离用户和实现者。在你的情况下，我认为抽象类更合适。

Answer 2

default方法是可覆盖的方法，但您的方案描述的实用方法既不是API的一部分，也不是可覆盖的。请注意，由于default方法只能根据接口中定义的public方法在实例上工作，即无法访问任何内部，因此没有区别：

interface MyInterface {
    default ReturnType method(Parameter parameter) {
    }
}

和

interface MyInterface {
    static ReturnType method(MyInterface instance, Parameter parameter) {
    }
}

关于该方法可以做什么。只有在default方法中，您可以在调用其他接口方法时省略限定this.，而在static方法中，必须使用instance.。但在任何一种情况下，您都可以调用public实例的所有MyInterface方法，但不能使用其他方法。

但static方法不可覆盖，您可以将其移至任何其他类，以避免它成为MyInterface API的一部分。但请注意，没有理由担心实用程序方法的辅助功能。由于它无法访问实现类的任何内部，因此无法提供调用者无法执行的任何操作。它只比在呼叫者网站上重新实现功能更舒服。因此，将方法移动到另一个类主要是为了表明不参与MyInterface API的意图。如果方法是public（以支持任意包中的实现），这没有坏处。

请参阅类StreamSupport中的方法。它们用于帮助实现不同包所需的Stream，但不是Stream接口API本身的一部分。事实上public方法不会造成任何伤害，它们不会提供您使用其他可用public API自己无法做到的任何事情。但是对于不需要自己动手的实现者来说很方便。

使用仅具有默认方法的接口作为实用程序类替代

2 个答案: