我正在编写一个构成 Java 类公共(public)接口(interface)一部分的方法。它广泛地允许调用者指定要分配给多个数据库实体的值 - 因此他们必须提供实体本身的 ID 以及要分配给它们的值。
我在将其实现为 List<Pair<Integer, Integer>> 之间犹豫不决或者只有两个 List<Integer>争论。两者显然都有效，并且都不会在我的方法中导致任何实现或效率问题。在任何情况下(2xn 数组)基本上都是相同的信息，只是条纹不同。
因此，我想就您认为哪个更好以及原因给出一些意见。
到目前为止，我看到的配对列表的优点:
- 更准确地反射(reflect)了实体之间的实际关系
- 消除某些类别的动态错误(例如不匹配的列表长度)
列表对的优点:
- 不依赖任何非 JDK 类(很简单，
Pair是一个概念) - 不需要构造任何辅助对象来携带数据
- 无论如何，调用者更有可能将参数放在单独的列表中，因此他们不需要在调用方法之前重新对齐数据
这两种情况都具有相同的类型安全性，以及参数不匹配的相同可能性(例如，应该先输入值，再输入 ID，而实际上应该是相反的)。后一个问题可以通过围绕 Integer 创建一个简单的包装器来避免。叫做 PrimaryKey ，它有自己的优点和缺点，并且无论如何都与这个问题正交，因为在这两种情况下都可以使用它。
然而，有一个中间立场可能是第三种选择 - 一个带有用于 objectId 和值的整数字段的普通容器类。这并没有征求编译器的帮助来确保对象通过键入是正确的，但它确实在分配中提供了额外的安全层。不过，我不认为我会这样做，因为我不喜欢用像这样的普通类污染公共(public)接口(interface)的想法。
最佳答案
我强烈建议将这些数据捆绑在一起，可能作为一对，但更像是作为一个特定的容器。这样您就可以自由地引入与这两个对象相关的额外功能。
将两个列表分开会很麻烦。您必须将两者一起传递并使它们保持同步。为此创建新对象的开销可以忽略不计，这正是 OOP 的设计目的(不要忘记，您只需为应用程序编写新的 Java 代码就可以创建非 JDK 类)。
我一直在创建这样的小类。它们强制执行强类型安全并提供增强和重构的范围。 IDE 可以更轻松地识别和执行重构。
关于java - 最好使用成对列表或两个列表？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1458793/