2

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

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 的构造在方法的不同用法中重复。

哪种代码约定可以应用于此问题设置？对这两种实施途径中的每一种都有什么影响？

4

1 回答 1

1

在我看来，仅仅为了“如果有人需要它”而在接口中声明方法的覆盖，都违反了 YAGNI 和接口隔离。

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

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

我可以向您建议一些不同的方法，如下所示：

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

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

于 2018-06-27T11:44:11.433 回答