java - 我应该在接口(interface)中为开发人员方便声明方法吗?

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

<分区>

我们最近讨论了为方便开发人员在接口(interface)中定义方法。给定以下最小示例:

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: 我们中的一位建议前瞻性地定义这两种方法,以免开发人员在想要使用接口(interface)的实现时编写样板代码。这将前瞻性地完成,不知道最终经常使用这两种方法中的哪一种。带有 String 类型参数的方法明确旨在方便开发人员。

实现路径 2: 另一个人指出,只应创建 setUri(Uri uri),因为您要求接口(interface)的实现者实现这两种方法,这会导致接口(interface)用户付出更多的努力(测试等),这会带来更好的类型安全性。

我看到了以下几个方面:

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

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

最佳答案

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

而且我也支持组合优于继承。接口(interface)是类的契约,这意味着“此类具有该功能”,定义可选方法并插入类来实现它根本无效。

根据整体设计结构,有不同的解决方案。

我可以向您推荐一些不同的方法,如下所示:

  • 抽象类:提供抽象类的一些常用方法
  • 封装:通过将其包装为对象来隐藏底层数据类型
  • UriFactory(工厂模式):根据给定类型的数据创建 uri
  • UriGenerationStrategy(策略模式):将 uri 策略的生成注入(inject)我们的类

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

关于java - 我应该在接口(interface)中为开发人员方便声明方法吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/51061652/

相关文章:

javascript - 在另一个方法内调用一个方法 JavaScript

design-patterns - 全局常量是反模式吗?

java - Spring Boot 服务静态资源

java - 为什么我的应用程序引擎 ID 生成器策略会生成大量数字?

oop - 自动将对象扩展到某个继承类

rest - 响应 200 错误或响应代码作为错误代码

soap - 如何创建向后兼容的 JAX-RS 和 JAX-WS API?

java - 为互斥请求参数设计 API 的更好方法是什么?

java - 如何(base64)将 protobuf 编码为字符串

Java:Arrays.sort 快速排序和归并排序