5

We have been discussing Tuple and its various possible uses. In almost all cases it sounds like root of evil, it makes design worse, and generally calls for a specialized class instead of Tuple everywhere it could be used.

It is supposedly close to DB but its hard to find a use for Tuple in db persistant logic code too.

Has anyone any real world good sample of Tuple use , preferably closer to some real world domain model problem or any use actualy.

Valentin Kuzub
  • 11,703
  • 7
  • 56
  • 93
  • Concerning the "root of evil" bit in your question, please see also: [Is using tuples in my .NET 4.0 code a poor design decision?](http://stackoverflow.com/questions/3017352/is-using-tuples-in-my-net-4-0-code-a-poor-design-decision) – stakx - no longer contributing Sep 11 '11 at 09:12

4 Answers4

4

Tuple is said to have been introduced to .NET 4 because some programming languages (let's say, for example, IronPython or F#) support tuples as a core feature of the language, and the .NET BCL team wanted to provide a uniform tuple type for such languages (for language interoperability reasons, I guess):

The BCL team decided to work with the F# team to standardize on one tuple type for the framework so that every language could benefit from them. (in Eric Lippert's answer to the SO question, What problem was the tuple designed to solve? )

Tuple does not make much sense in the C# language IMHO, because C# doesn't support tuples and some associated language constructs very well; e.g. tuple "explosion": spreading a tuple over a function's parameters, or taking a function's return values (in the form of a Tuple) and spreading it over several local variables:

Tuple<int,int>  GetFoo() { … }
//     v   v
int   (a,  b) = GetFoo();  // C# doesn't support this tuple-related syntax.

That being said, if you're writing only C# code, you can usually find "better", more structured solutions than using Tuple. For example, using tuples to return more than one value from a method (such as in GetFoo above) is quick and convenient, but the return value doesn't have any inherent structure — you might do better with a struct or class type, if you're willing to take some additional time to define it.

Community
  • 1
  • 1
stakx - no longer contributing
  • 83,039
  • 20
  • 168
  • 268
  • "(here on SO), I've read it and found conceptually helpful for my grasping the idiosyncrasies of .NET collections in @JoelMuelle's comment to [Philippe Leybaert's answer](http://stackoverflow.com/a/3018107/200449) to question "Is Using Tuples in my .NET 4.0 Code a Poor Design Decision?" – Gennady Vanin Геннадий Ванин Apr 01 '13 at 10:20
3

There are many languages where it's legal to return multiple values (something like return (a, b) instead of using ref or out (these are considered another root of all evils) .) Tuple solves this problem.

Let's look at int Math.DivRem(int, int, out int). It could be refactored in Tuple<int, int> Math.DivRem(int, int). If you think that in this case instead of Tuple you should use special classes, well, for delegates the direction is the opposite: after creating hundred (tens in reality) of specialized delegates MS has created generic Action and Func and has begun using them.

(We will ignore that Tuple is a family of classes so using them is "slow". Premature optimization and all that beautiful things :-) )

I'll add that Tuple solves the problem of writing short code blocks here on SO :-)

xanatos
  • 109,618
  • 12
  • 197
  • 280
2

the question is very open ended but I try anyhow.

  1. Tuples are great in a local context (inside methods) to shorten your algorithm, just like annonymous functions are.
  2. If you use good Types (meaningfull names) Tuple<Result, Message> are very readable only the Item1, Item2 things are not so nice
  3. this comes IMHO from functional programming (just like Func<_,_> and Action<_>) and can be very nice to have at times - Tuples are used to a great extent there - look at F# there tuples are the way to give multiple function-parameters instead of making a

function that returns a function that returns a value

for example :)

Just don't use them in your Big Picture (you might call this your design) but for your local implementations they are great

Random Dev
  • 51,810
  • 9
  • 92
  • 119
0

You don't usually use expose them as a part of a public interface, that's not what they were meant for (at least in C#). They just come in handy when you are too lazy to write your own class used only to solve a small problem.

I've found them especially convenient with Dictionaries. If you have a private dictionary which uses a key consisted of two or more properties, in order for it to work you need to make sure that you use compare-by-value semantics and implement hash code properly (or provide a custom Comparer). A Tuple already does this for you.

vgru
  • 49,838
  • 16
  • 120
  • 201