Java 我应该在接口中声明方便开发人员的方法吗？

我们最近讨论了如何定义接口中方便开发人员的方法。给出以下最小示例：

public interface aInterface{

    public void setUri(Uri uri);
    public void setUri(String uri);

}

public class aClass implements aInterface{
  @Override
  public void setUri(Uri uri){
      //do something with uri
  }

  @Override
  public void setUri(String uri){
      set Uri(new Uri(uri));
  }

}

实现途径1:我们中的一位建议前瞻性地定义这两种方法，以避免开发人员在想要使用接口实现时编写锅炉板代码。这将是前瞻性的，不知道这两种方法中的哪一种最终经常被使用。带有字符串类型参数的方法明确地是为了方便开发人员

实现途径2:另一个人表示，只应创建setUri（Uri Uri），因为您要求接口的实现者实现这两种方法，这会为接口用户带来更高的努力（测试等），从而提高类型安全性

我看到以下几个方面：

• 与雅格尼原则相对应，两种方法中只应创建一种——更适合预期功能的方法
• 如果通常只有字符串可用，那么只实现

  setUri（Uri）

  -方法可能会导致更多的锅炉板代码。特别是当

  Uri

  -类型的构造更复杂时。最后，这违反了DRY原则，因为

  Uri

  -类型的构造在方法的不同用法中重复

哪种代码约定可应用于此问题设置？

---

这两种实现途径的结果是什么？

在我看来，在接口中声明方法重写只是为了“如果有人需要怎么办”，这两种方法都违反了YAGNI和接口隔离

我也支持组合而不是继承。接口是类的契约，这意味着“这个类有那个能力”，定义可选方法并推动类实现它是完全无效的

有不同的解决方案取决于总体设计结构

我可以向您推荐以下几种不同的方法：

• 抽象类：提供抽象类的一些常用方法
• 封装：通过将底层数据类型包装为对象来隐藏它
• UriFactory（工厂模式）：从给定类型的数据创建uri
• UriGenerationStrategy（策略模式）：将uri策略的生成注入到我们的类中

---

根据您当前的项目结构和设计，以上所有内容可能有用，也可能毫无意义。

或将

setUri（String）

定义为接口上的默认方法，因此可以使用，但接口的实现者无需编写该方法。这是否在库、远程/RMI接口中，只有一个组件？khelwood的策略弥补了可怕的“接口上的默认方法”（反）功能的不足。@DawoodibnKareem默认方法实际上没有其他存在的理由。它们使尝试并找到每个方法的Javadoc更加令人兴奋。