元组应该互相分类吗？

Question

给定OOP语言中的一组元组类：Pair，Triple和Quad，Triple子类Pair和Quad子类Triple？

正如我所看到的，问题在于Triple是否应该可以替换为Pair，同样Quad可以替换为Triple或Pair。 Triple 是否一对和四元也三元组和一对。

在一个上下文中，这样的关系对于可扩展性可能是有价值的 - 今天这个东西返回一对东西，明天我需要它返回一个Triple而不破坏现有的调用者，他们只使用三个中的前两个。 / p>

另一方面，它们应该是不同的类型吗？我可以看到更强大的类型检查的好处 - 你不能将Triple传递给期望一对的方法。

我倾向于使用继承，但是真的很感激别人的意见吗？

PS：如果重要，这些课程（当然）是通用的。

PPS：在一个更主观的方面，名称应该是Tuple2，Tuple3还是Tuple4？

---

编辑：我认为这些更像松散耦合的群体;不是专门用于x / y x / y / z坐标之类的东西，尽管它们可以用于此类。这需要从方法中获取多个返回值的通用解决方案，但需要使用非常简单的语义形式。

那就是说，我对其他人实际使用元组的所有方式感兴趣。

Answer 1

在我看来，你应该创建一个通用的Tuple接口（或使用类似上面提到的Collection），并让你的对和3元组类实现该接口。这样，您可以利用多态，但也允许一对使用比任意大小的元组更简单的实现。您可能希望使您的Tuple接口包含.x和.y访问器作为前两个元素的简写，而较大的元组可以根据索引较高的项目实现自己的缩写。

Answer 2

这取决于你需要的语义 -

• 一对对立在语义上与3元组的类似对象不兼容
• 极地空间中的一对坐标在欧几里德空间中与3元组坐标在语义上不兼容

如果你的语义是简单的组合，那么通用类Tuple＆lt; N＆gt;会更有意义

Answer 3

不同长度的元组是不同的类型。 （好吧，无论如何，在许多类型的系统中。）在强类型语言中，我不认为它们应该是一个集合。

这是一件好事，因为它可以确保更安全。返回元组的地方通常会与它有一些耦合的信息，隐含的知识是每个组件是什么。如果你在一个元组中传递的值多于预期，那就更糟了 - 那是什么意思？它不适合继承。

另一个潜在的问题是，如果您决定使用重载。如果元组继承，那么重载决策将失败。但这可能是反对超载的更好理由。

当然，如果您有特定用例并发现某些行为会对您有所帮助，那么这一切都不重要。

编辑：如果您需要一般信息，请尝试仔细阅读一些Haskell或ML系列（OCaml / F＃），看看它们是如何使用的，然后形成自己的决定。

Answer 4

与大多数设计相关的问题一样，答案是 - 这取决于。

如果您正在寻找传统的Tuple设计，Tuple2，Tuple3等是可行的方法。继承的问题在于，首先Triplet不是Pair的类型。你会如何为它实现equals方法？ Triplet是否与前两个项目相同？如果你有一对Pairs，你可以添加三元组，反之亦然？如果你的域名没问题，你可以继承。

任何情况下，都有一个接口/抽象类（可能是元组），所有这些实现。

Answer 5

我会选择0,1,2或无穷大。例如null，1个对象，你的Pair类，或者某种类型的集合。

你的对甚至可以实现一个Collection接口。

如果三个或四个项目之间存在特定关系，则应该将其命名。

[也许我错过了这个问题，但我想不出一个我想以通用的方式专门链接3件事的情况]

Answer 6

Gilad Bracha blogged about tuples，我找到了有趣的读物。

他提出的一点（无论是否正确，我还不能判断）是：

  

文字元组最好定义为只读。其中一个原因是只读元组更具多态性。长元组是短元组的子类型：

     

{S。 T. U. V}＆lt; = {S。 T. U}＆lt; = {S T}＆lt; = {S}

     

[和]只读元组是协变的：

     

T1＆lt; = T2，S1 <= S2 ==＆gt; {S1。 T1}＆lt; = {S2。 T2}

这似乎表明我倾向于使用继承可能是正确的，当他说三元组不一对时，它会与amit.dev相矛盾。