And*_*yle 6 java collections interface
我正在编写一个构成Java类公共接口一部分的方法.它广泛允许调用者指定要分配给多个数据库实体的值 - 因此它们必须提供实体本身的ID以及要分配给它们的值.
我在实现这个List<Pair<Integer, Integer>>或两个List<Integer>论点之间摇摆不定.两者都显然有效,并且在我的方法中都不会导致任何实现或效率问题.它在任何情况下(2xn数组)基本上都是相同的信息,只是条纹不同.
所以我想对你认为哪一个会更好,以及为什么会有一些意见.
到目前为止我看到的对列表的优点:
这对列表的优点:
Pair把握作为一个概念)两种情况都具有相同的类型安全性,以及参数不匹配的相同可能性(例如,首先输入值,而当它应该相反时输入ID秒).后一个问题可以通过创建一个简单的包装器来避免,这个包装器Integer被称为类似的东西PrimaryKey,它有自己的优点和缺点,并且无论如何都与这个问题正交,因为这在两种情况下都可以使用.
然而,有一个中间立场可能成为第三种选择 - 一个简单的容器类,其中包含objectId和value的整数字段.这并没有使编译器帮助确保通过键入来确保对象是正确的,但它确实在赋值中提供了额外的安全层.我不认为我会这样做,因为我不喜欢用像这样的普通类来污染公共接口的想法.
Bri*_*new 23
我强烈建议将这些数据捆绑在一起,可能是一对,但更多是作为一个特定的容器.这样你就可以自由地引入与这两个对象相关的额外功能.
保持两个列表分开将是一个痛苦.你必须将两者一起传递并使它们保持同步.为此创建新对象的开销可以忽略不计,而且正是OOP的设计目标(您只需为应用程序编写新的Java代码就可以创建非JDK类,不要忘记).
我一直在创建像这样的小班.它们强制实施强大的类型安全性,并提供增强和重构的范围.IDE可以更容易地识别和执行重构.
我觉得你所经历的分析已经很好地确定了两种方法的优缺点.
我也倾向于使用这个Pair课程,引用你列出的优势:
- 更准确地反映实体之间的实际关系
- 消除某些类型的动态错误(例如列表长度不匹配)
对我来说最重要的是最重要的一个.
始终编写演示意图的代码.不要仅仅考虑实现来编写代码.
使用类似的类Pair表示存在一对表示ID和实际实体本身的值的意图.它还表明,一个Pair对象是一个需要一起处理的离散数据单元 - 不能因为有两个独立List的ID和实体而产生这种情况.
| 归档时间: |
|
| 查看次数: |
3755 次 |
| 最近记录: |