在存储 API 中定义单数与复数获取的理想方法是什么？

发布于 2024-12-10 08:33:24 字数 779 浏览 1 评论 0原文

我的应用程序中有一个内部存储层，用于处理 Foo 对象。在 Get 操作期间，数据层对集群获取有显着的好处，但我实际上只有大约 10% 的时间进行多次获取。以下是我考虑过的各种方法：

方法 A：

interface FooStorage {
  Foo getFoo(String name);
  List<Foo> getFoos(List<String> names);
}

方法 B：

interface FooStorage {
  List<Foo> getFoos(List<String> names);
}
class StorageUtility {
  public static <T> T firstOrNull(List<T> data) { ... }
}

方法 C：

interface FooStorage {
  List<Foo> getFoos(String... names);
}
class StorageUtility {
  public static <T> T firstOrNull(List<T> data) { ... }
}

方法 A 的缺点是需要支撑的表面较大。
方法 B 的缺点是让消费者在 90% 的时间我不需要它时构建一个列表。方法 C 的缺点是 10% 的时间将列表复制到数组的开销。

有规范的正确方法来做到这一点吗？

原文

I've got an internal storage layer in my application, which handles Foo objects. During Get operations, the data layer has significant benefits to clustering gets, but I only actually do multiple gets about 10% of the time. Here are various approaches I've considered:

Approach A:

interface FooStorage {
  Foo getFoo(String name);
  List<Foo> getFoos(List<String> names);
}

Approach B:

interface FooStorage {
  List<Foo> getFoos(List<String> names);
}
class StorageUtility {
  public static <T> T firstOrNull(List<T> data) { ... }
}

Approach C:

interface FooStorage {
  List<Foo> getFoos(String... names);
}
class StorageUtility {
  public static <T> T firstOrNull(List<T> data) { ... }
}

The downside to Approach A is having a larger surface that I need to support.
The downside to Approach B is having the consumer build a List when 90% of the time I don't need it.
The downside to Approach C is the overhead of copying a list to an array 10% of the time.

Is there a canonical right way to do this?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

归属感 2024-12-17 08:33:24

在这种情况下，我倾向于采用以下构造：

Foo getFoo(String name) {
    return firstOrNull(getFoos(name));
}
List<Foo> getFoos(String ... names) {
    return getFoos(Arrays.asList(names));
}
List<Foo> getFoos(List<String> names) {
    ....
}

您的客户端每次都应该使用最合适的方法，并且如果您后来发现性能需要更有针对性的方法 getFoo(name) ，您可以重新实现该单一方法。

我认为保持消费者代码的可读性（避免仅仅为了满足 API 而创建列表）比在存储系统的接口/实现中保存几行代码更重要。

In this type of situation, I would tend go with the following construct:

Foo getFoo(String name) {
    return firstOrNull(getFoos(name));
}
List<Foo> getFoos(String ... names) {
    return getFoos(Arrays.asList(names));
}
List<Foo> getFoos(List<String> names) {
    ....
}

Your client should use the most appropriate method each time, and if you latter discover that performance requires a more targeted approach for getFoo(name), you can re-implement that single method.

I would argue that it is more important to keep the consumer code readable (avoid creating lists just to satify the API), than saving a few lines of code in the interface/implementation of the storage system.

回复收藏 0 原文

~没有更多了~