随着在 .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; }
所以撇开我错过元组的可能性不谈,元组的例子是一个糟糕的设计选择吗?对我来说,它似乎不那么混乱,但不像自我记录和干净。这意味着使用 type ResultType,稍后将非常清楚类的每个部分的含义,但是您需要维护额外的代码。有了它,Tuple<string, int>您将需要查找并弄清楚每个Item代表什么,但您编写和维护的代码更少。
ResultType
Tuple<string, int>
Item
您在此选择方面的任何经验将不胜感激。
如果您控制创建和使用元组,那么元组非常棒——您可以维护上下文,这对于理解它们至关重要。
但是,在公共 API 上,它们的效果较差。消费者(不是您)必须猜测或查找文档,尤其是对于Tuple<int, int>.
Tuple<int, int>
我会将它们用于私有/内部成员,但将结果类用于公共/受保护成员。