在C＃代码中使用.NET 4.0元组是否是糟糕的设计决策？

在.net 4中添加了Tuple类之后，我一直试图确定在设计中使用它们是否是一个错误的选择。按照我的看法，元组可以是编写结果类的捷径（我敢肯定，还有其他用途）。

所以这：

public class ResultType
{
    public string StringValue { get; set; }
    public int IntValue { get; set; }
}

public ResultType GetAClassedValue()
{
    //..Do Some Stuff
    ResultType result = new ResultType { StringValue = "A String", IntValue = 2 };
    return result;
}

等效于此：

public Tuple<string, int> GetATupledValue()
{
    //...Do Some stuff
    Tuple<string, int> result = new Tuple<string, int>("A String", 2);
    return result;
}

所以，撇开，我很想念元组点的可能性，是一个例子元组设计不好的选择呢？在我看来，这似乎不太杂乱，但没有自我记录和干净。这意味着与类型ResultType，这是非常以后清除类的手段对各部分，但你有额外的代码维护。使用，Tuple<string, int>您将需要查找并弄清楚每个Item代表什么，但是您只需编写和维护较少的代码。

您在此选择方面的任何经验将不胜感激。

如果您同时控制创建和使用元组，则元组非常有用-您可以维护上下文，这对于理解它们至关重要。

但是，在公共API上，它们的效果较差。使用者（不是您）必须猜测或查找文档，尤其是对于Tuple<int, int>。

我会将它们用于私有/内部成员，但将结果类用于公共/受保护成员。

这个答案也有一些信息。

在我看来，元组是编写结果类的捷径（我敢肯定，还有其他用途）。

实际上，还有其他有价值的用途Tuple<> -其中大多数涉及抽象化共享相似结构的特定类型组的语义，并将它们简单地视为有序的值集。在所有情况下，元组的好处是它们避免使用仅公开数据类的属性（而不是方法）使名称空间混乱。

这是合理使用的示例Tuple<>：

var opponents = new Tuple<Player,Player>( playerBob, playerSam );

在上面的示例中，我们要代表一对对手，元组是将这些实例配对的一种便捷方法，而无需创建新类。这是另一个例子：

var pokerHand = Tuple.Create( card1, card2, card3, card4, card5 );

扑克手可以看作只是一组纸牌-元组（可能是）表达该概念的一种合理方法。

抛开我遗漏Tuples的可能性，Tuple的示例是否是错误的设计选择？

将强类型Tuple<>实例作为公共类型的公共API的一部分返回并不是一个好主意。如您所知，元组要求相关各方（图书馆作者，图书馆用户）提前就所使用的元组类型的目的和解释达成协议。创建直观而清晰的API充满挑战，Tuple<>仅公开使用会掩盖API的意图和行为。

匿名类型也是元组的一种 -但是，它们是强类型的，并且允许您为属于该类型的属性指定清晰，有用的名称。但是匿名类型很难跨不同的方法使用-匿名类型主要是为支持LINQ等技术而添加的，其中投影会产生我们通常不希望分配名称的类型。（是的，我知道编译器会合并具有相同类型和命名属性的匿名类型）。

我的经验法则是： 如果要从公共接口返回它，请将其命名为type。

使用元组的另一个经验法则是： 尽可能清楚地命名方法参数和类型的localc变量Tuple<>-使名称代表元组元素之间关系的含义。想想我的var opponents = ...例子。

这是一个现实情况的示例，在该示例中，我曾经Tuple<>避免声明仅在自己的程序集中使用的仅数据类型。这种情况涉及这样一个事实，当使用包含匿名类型的通用字典时，很难使用该TryGetValue()方法在字典中查找项目，因为该方法需要一个out无法命名的参数：

public static class DictionaryExt 
{
    // helper method that allows compiler to provide type inference
    // when attempting to locate optionally existent items in a dictionary
    public static Tuple<TValue,bool> Find<TKey,TValue>( 
        this IDictionary<TKey,TValue> dict, TKey keyToFind ) 
    {
        TValue foundValue = default(TValue);
        bool wasFound = dict.TryGetValue( keyToFind, out foundValue );
        return Tuple.Create( foundValue, wasFound );
    }
}

public class Program
{
    public static void Main()
    {
        var people = new[] { new { LastName = "Smith", FirstName = "Joe" },
                             new { LastName = "Sanders", FirstName = "Bob" } };

        var peopleDict = people.ToDictionary( d => d.LastName );

        // ??? foundItem <= what type would you put here?
        // peopleDict.TryGetValue( "Smith", out ??? );

        // so instead, we use our Find() extension:
        var result = peopleDict.Find( "Smith" );
        if( result.First )
        {
            Console.WriteLine( result.Second );
        }
    }
}

PS还有另一种（更简单的）方法可以解决字典中由匿名类型引起的问题，那就是使用var关键字让编译器为您“推断”类型。这是该版本：

var foundItem = peopleDict.FirstOrDefault().Value;
if( peopleDict.TryGetValue( "Smith", out foundItem ) )
{
   // use foundItem...
}

元组可能是有用的...但是稍后它们也会很痛苦。如果您有一个返回的方法，Tuple<int,string,string,int>您以后将如何知道这些值。是他们ID, FirstName, LastName, Age还是他们UnitNumber, Street, City, ZipCode。

从C＃程序员的角度来看，元组对于CLR来说是相当强大的。如果您拥有长度不等的项目集合，则不需要它们在编译时具有唯一的静态名称。

但是，如果您有一个固定长度的集合，这意味着该集合中固定的位置分别具有特定的预定义含义。而且它总是不如给他们适当的静态的名字在这种情况下，而不是记住的意义Item1，Item2等等。

C＃中的匿名类已经为元组的最常见私有用法提供了一个极好的解决方案，并且为项目赋予了有意义的名称，因此在这种意义上它们实际上是优越的。唯一的问题是它们不能从命名方法中泄漏出来。我更希望看到解除限制（也许仅适用于私有方法），而不是对C＃中的元组有特定的支持：

private var GetDesserts()
{
    return _icecreams.Select(
        i => new { icecream = i, topping = new Topping(i) }
    );
}

public void Eat()
{
    foreach (var dessert in GetDesserts())
    {
        dessert.icecream.AddTopping(dessert.topping);
        dessert.Eat();
    }
}

与关键字相似var，它旨在提供方便-但很容易被滥用。

以我最卑微的观点，不要把自己Tuple当作返回类。如果服务或组件的数据结构需要它，请私下使用它，但是从公共方法返回格式正确的知名类。

// one possible use of tuple within a private context. would never
// return an opaque non-descript instance as a result, but useful
// when scope is known [ie private] and implementation intimacy is
// expected
public class WorkflowHost
{
    // a map of uri's to a workflow service definition 
    // and workflow service instance. By convention, first
    // element of tuple is definition, second element is
    // instance
    private Dictionary<Uri, Tuple<WorkflowService, WorkflowServiceHost>> _map = 
        new Dictionary<Uri, Tuple<WorkflowService, WorkflowServiceHost>> ();
}

使用like这样的类ResultType更加清晰。您可以给类中的字段赋予有意义的名称（而使用元组时，它们将被称为Item1和Item2）。如果两个字段的类型相同，这一点就尤为重要：名称清楚地区分了它们。

如何在decorate-sort-unecorate模式中使用Tuples？（适用于Perl人的Schwartzian转换）。当然，这是一个人为的示例，但是Tuples似乎是处理此类问题的好方法：

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            string[] files = Directory.GetFiles("C:\\Windows")
                    .Select(x => new Tuple<string, string>(x, FirstLine(x)))
                    .OrderBy(x => x.Item2)
                    .Select(x => x.Item1).ToArray();
        }
        static string FirstLine(string path)
        {
            using (TextReader tr = new StreamReader(
                        File.Open(path, FileMode.Open)))
            {
                return tr.ReadLine();
            }
        }
    }
}

现在，我可以使用两个元素的Object []或在此特定示例中使用两个元素的字符串[]。关键是我可以将任何东西用作内部使用且非常易于阅读的元组的第二个元素。

IMO这些“元组”基本上都是带有未命名成员的公共访问匿名struct类型。

该唯一的地方，我会用元组是当你需要快速团块一些数据一起，在非常有限的范围。 数据的语义应该很明显，因此代码不难阅读。因此int，int对（row，col）使用元组（，）似乎是合理的。但是，我很难找到struct具有命名成员的A的优势（因此不会出错，并且行/列不会被意外地互换）

如果您要将数据发送回呼叫者，或者接受来自呼叫者的数据，则实际上应该使用struct带有命名成员的。

举一个简单的例子：

struct Color{ float r,g,b,a ; }
public void setColor( Color color )
{
}

元组版本

public void setColor( Tuple<float,float,float,float> color )
{
  // why?
}

我没有看到使用元组代替具有命名成员的结构的任何优势。使用未命名成员对于代码的可读性和可理解性而言是一个后退。

元组给我打招呼是一种避免struct使用实际的命名成员创建的懒惰方式。元组的过度使用，在您真正感觉到您/或其他遇到您的代码的人将需要命名成员的地方，如果我看到过，则是Bad Bading™。

不要判断我，我不是专家，但是现在有了C＃7.x中的新元组，您可以返回类似以下内容：

return (string Name1, int Name2)

至少现在您可以命名它，开发人员可能会看到一些信息。

当然要看情况！如您所说，当您希望将某些项目组合在一起以供本地使用时，元组可以节省代码和时间。与传递具体类相比，您还可以使用它们来创建更多的通用处理算法。我不记得有多少次希望我拥有KeyValuePair或DataRow之外的东西可以将某个日期从一种方法快速传递给另一种方法。

另一方面，很可能会过度使用它并绕过元组，您只能在其中猜测它们所包含的内容。如果要在各个类之间使用元组，则最好创建一个具体的类。

当然，在适度使用元组可以导致更简洁和可读的代码。您可以参考C ++，STL和Boost来获取在其他语言中如何使用元组的示例，但最后，我们所有人都必须进行实验以找到它们最适合.NET环境的方式。

元组是.NET 4中无用的框架功能。我认为C＃4.0错失了很大的机会。我本来希望有具有命名成员的元组，所以您可以按名称而不是Value1，Value2等访问元组的各个字段。

它将需要语言（语法）的更改，但这将非常有用。

我个人不会将Tuple用作返回类型，因为没有迹象表明这些值代表什么。元组有一些有价值的用途，因为与对象不同，元组是值类型，因此了解相等性。因此，如果我需要一个多部分键，则将它们用作字典键；如果要按多个变量进行分组，并且不希望使用嵌套分组（谁想要嵌套的分组？），它们将用作GroupBy子句的键。要克服极端冗长的问题，可以使用辅助方法创建它们。请记住，如果您经常访问成员（通过Item1，Item2等），则可能应该使用其他结构，例如struct或匿名类。

我在许多不同的场景中都使用了元组Tuple和新元组，ValueTuple并得出以下结论：不要使用。

每次，我遇到以下问题：

• 由于缺乏强有力的命名，代码变得不可读；
• 无法使用类层次结构功能，例如基类DTO和子类DTO等；
• 如果在多个地方使用它们，您最终将复制并粘贴这些难看的定义，而不是使用干净的类名。

我的看法是，元组是C＃的缺点，而不是功能。

我对Func<>和的批评有点相似，但严厉得多Action<>。这些在许多情况下都很有用，尤其是简单Action和Func<type>变体，但是除此之外，我发现创建委托类型更加优雅，可读，可维护，并为您提供更多功能，例如ref/ out参数。