为了方便开发人员，我应该在接口中声明方法吗？ [关闭]答案

【问题标题】：Should I declare methods for developers convenience in an interface? [closed]为了方便开发人员，我应该在接口中声明方法吗？ [关闭]
【发布时间】：2018-12-06 06:47:13
【问题描述】：

我们最近讨论了定义方法以方便开发人员在接口中使用。给定以下最小示例：

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： 我们中的一个人建议预先定义这两种方法，以便开发人员在他们想要使用接口的实现时免于编写样板代码。这将前瞻性地完成，不知道最终经常使用这两种方法中的哪一种。带有 String-type-parameter 的方法是为了方便开发人员而明确设计的。

实现途径 2： 另一个人说应该只创建 setUri(Uri uri)，因为你要求接口的实现者实现这两种方法，这会导致接口用户的工作量更大（测试等），这会带来更好的类型安全性。

我看到以下几个方面：

对应于 YAGNI 原则，只应创建两种方法中的一种 - 一种更适合预期功能的方法
如果通常只有一个字符串可用，那么只实现setUri(Uri)-方法可能会导致更多样板代码。特别是如果Uri-Type 的构造更复杂。最后，这违反了 DRY 原则，因为 Uri-Type 的构造在方法的不同用法中会重复。

哪种代码约定可以应用于这个问题设置？对这两种实施途径的影响是什么？

【问题讨论】：

或者将setUri(String)定义为接口上的默认方法，这样可以使用但接口的实现者不必编写方法。
这是在库、远程/RMI 接口中，只有一个组件吗？
khelwood 的策略是可怕的“接口上的默认方法”（反）功能的一种可取之处。
@DawoodibnKareem 默认方法实际上没有其他存在的理由
它们让尝试查找每个方法的 Javadoc 变得更加令人兴奋。

标签： java oop api-design coding-style convenience-methods

【解决方案1】：

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

而且我还支持组合而不是继承。接口是类的契约，这意味着“这个类具有那种能力”，定义可选方法并将类推送到实现它根本无效。

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

我可以建议你一些不同的方法如下：

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

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

【讨论】：