Java 使用仅包含默认方法的接口作为实用程序类替换

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

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

采用单独的具体UTIL类别是否是达到这一目的的更好手段？或者用所需的方法创建接口的抽象实现，并让客户机进行扩展

---

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

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

default

方法是可重写的方法，但您的场景描述的实用程序方法既不是API的一部分，也不是可重写的。请注意，由于

default

方法只能在接口中定义的

public

方法中对实例起作用，即不能访问任何内部构件，因此以下两者之间没有区别：

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

及

关于该方法可以做什么。只是在

默认

方法中，调用其他接口方法时可以省略限定的

this.

，而在

静态

方法中，必须使用

实例。

。但在任何一种情况下，您都可以调用

MyInterface

实例的所有

public

方法，而不调用其他方法

但是

static

方法是不可重写的，您可以将其移动到任何其他类，以避免它成为

MyInterface

的API的一部分。但是请注意，没有什么理由担心实用方法的可访问性。因为它不能访问实现类的任何内部，所以它不能提供调用方无法提供的任何东西。这只会让它比在调用方的站点上重新实现功能更舒适。因此，将该方法移到另一个类中主要是为了证明它不属于

MyInterface

的API。如果方法是

public

（支持任意包中的实现），则没有什么害处

---

例如，请参见类中的方法。它们用于帮助实现不同包所需的

流

s，但不是

流

接口API本身的一部分。事实上，有

public

的方法不会造成任何伤害，它们不会提供使用其他可用的

public

api无法自己做的任何事情。但是对于不需要自己完成的实现者来说，这很方便。

我要补充的是，如果管道中的其他接口不能从同一个接口继承，您可能需要将抽象超类的实现拉入一个单独的实用程序类中。也就是说，如果类A1、A2和A3实现了AbstractA，而类B1、B2和B3实现了AbstractB，那么由于您需要AbstractA和AbstractB中的内部方法，您必须将其拉入一个单独的类中以避免重复。好的，因此，我从您的回答中得出的结论是，将其作为接口中的默认方法或通过单独的具体utils类公开似乎是可以的-可访问性在这里似乎不太重要，因为它在给定的上下文中似乎是无害的。如果是这样的话，我倾向于在接口中使用默认方法，因为所讨论的公共功能需要调用方的实例，并且将其保持在接口中与此需求无缝地一致。我不必最终将实例作为参数传递给单独类的静态方法。别忘了

default

方法是可重写的，这是API用户最大的困扰，除此之外，这只是关于您是否希望该方法显示在

接口

方法列表中的问题。您认为这不正确的可能重复，是正确的。这是对接口用途的滥用——很像“常量接口反模式”。接口用于定义类型。如果您定义的类型不合理，那么它可能不应该是接口。

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