为什么Tuple不是继承自Tuple
本文关键字：T1 T2 Tuple 继承 为什么 T3 | 更新日期: 2023-09-27 18:01:48
从c# 4.0开始，Tuple类可用。为什么具有三个元素的Tuple不是具有两个元素的Tuple的子类?
这在定义操作First : Tuple<T1,T2> -> T1时非常有用，该操作将适用于任何元组，而不管附加项的数量。
此外，由于元组的元素是只读的，为什么Tuple<T1,T2>不是协变的?(例如，ITuple<Foo,Bar>也是ITuple<SuperFoo,SuperBar>)
因为对于高长度来说，不必要的深度继承是非常糟糕的设计。唯一合理的继承是来自某个GeneralTuple，但是我不能想出任何可以被所有n元组共享和使用的代码。.NET的设计师也不能。
n元组的递归定义为(n-1)元组加上一个元素是不自然的，因此很笨拙，因为在一个真正的元组中所有的元素都是相等的。假设你有{1, 2, 3}。根据你的提议，有两种表示方式:{{1, 2}, 3}和{1, {2, 3}}，这两种方式都不能合理地选择，这证明了表示是错误的，因为它需要人工&除了漂亮而不冗余的数学定义之外，还有多余的约定。
TL;DR因为c#语言不是MATLAB语言，不是Wolfram语言，不是Prolog语言更不是f#语言。语言设计和类库设计旨在提供可用于生产的、强大的、易于使用的、高效的、图灵完备的通用语言(参见Wikipedia: c#设计目标)。c#并不是一种表达和操纵思想的语言
为什么3元素的元组不是2元素的元组的子类?
为什么微软的某个人决定这样写http://referencesource.microsoft.com/#mscorlib/system/tuple.cs ?去问微软的设计师吧。
这个"为什么"的问题在现实生活中没有意义(也不适合Stack Overflow问题的格式)。如果你问我"如何"在我的代码中使用它，例如，我如何定义GeneralTuple，这将允许我创建一些抽象的泛型函数库…这样的问题才会有意义，才会有可用的答案。
从我的角度来看，这个设计决定可能是由元组的性质和历史决定的。据我所知，它来自Linda计算模型，其中tuples的基本数据结构存在于关联内存中，称为元空间。元组只是简单的数据结构(没有带有方法和行为的OOP对象)，类似于今天所说的数据传输对象(data Transfer Object, DTO)。它一直只是一个简单的数据结构，是联想记忆的一部分。需要的是简单和快速的读/写/传输。这也是c#内置元组现在所支持的
为什么Tuple<T1,T2>不是协变的(即Tuple<Foo,Bar>也是Tuple<SuperFoo,SuperBar>)?
因为这不是泛型类的工作方式。这个问题也在Stack Overflow上解释过几次，参见c#中的泛型继承类型限制