6

how is a tuple different from a class? instead of the following code, we can make a class with 3 fields and make objects from it. How is this Tuple different from that? Is it only reducing the code we write or does it have something to do with speed as well, given the fact that you can't change the items in a tuple. 

Tuple<int, string, bool> tuple = new Tuple<int, string, bool>(1, "cat", true);
nasim
  • 725
  • 2
  • 8
  • 17
  • 2
    maybe worth mentioning,the properties are only getters, so you can't change them after you have created them. – default Dec 18 '14 at 23:09
  • It should be noted that tuples are of *much* more utility in F#, where pattern matching is a large part of the language, and syntax is built around the concept: http://msdn.microsoft.com/en-us/library/dd233200.aspx. – Preston Guillot Dec 18 '14 at 23:11

4 Answers4

13

It saves you from having to define a new class with custom properties.

It does define equality by the value of the three items, which is something that a bare-bones class would not do without custom coding. That plus the fact that it's immutable makes it a reasonable candidate for a hash key in a Dictionary.

One drawback is that the properties are vanilla Item1, Item2, etc., so they don't provide any context to the values within them, where properties like ID, Name, Age would.

D Stanley
  • 149,601
  • 11
  • 178
  • 240
  • 1
    Would not have thought of them as a good `Dictionary` key. Of course, you have to make a *new* one to compare it against... – BradleyDotNET Dec 18 '14 at 23:07
  • 1
    A `Tuple` containing value types is actually incredibly poor to use as a key due to the fact the `GetHashCode` and `Equals` implementations box each of the values it contains! See [this question](http://stackoverflow.com/questions/21084412/net-tuple-and-equals-performance) for additional info. – Lukazoid Dec 18 '14 at 23:08
  • 1
    @Lukazoid Fair point, but I was comparing the _practicality_ of using it as a key versus the _performance_. Certainly it's not the most performant, but "Incredibly poor" is an exaggeration IMHO. It may not be significant depending on the usage. – D Stanley Dec 18 '14 at 23:11
  • 1
    @DStanley That was a miswording on my part, what I meant to say was implementation of those methods on `Tuple` is incredibly poor IMO and as a result it is not always an ideal choice for `Dictionary` keys. I do accept sometimes it is insignificant however I also believe it is worth highlighting as there are cases it can have a non-insignificant impact. – Lukazoid Dec 18 '14 at 23:19
10

Tuple is a class. One that holds any data you want (in terribly named properties like Item1).

You should be making classes instead so your code is more readable/maintainable. Its primary function is as a "quick fix" when you want to associate pieces of data without making a class to hold them.

BradleyDotNET
  • 60,462
  • 10
  • 96
  • 117
  • 1
    Agree, you should generally not use them. For local variables you can use anonymous types instead. For stuff that's passed around it's better to create separate types. – MarcinJuraszek Dec 18 '14 at 23:06
4

Tuples are in my opinion an invitation to bad data modeling. Instead of creating a proper model you get a generic object that can hold n item properties. The naming is very generic too.. Item1..ItemN

TGH
  • 38,769
  • 12
  • 102
  • 135
1

You use Tuples as a mean to pass data between method call without having to define a new class. Typically use to return multiple pieces of data from a method rather than use "out" parameters.

Keep in mind that out parameter cannot be use with async/await methods, this is where Tuples come in handy.

You probably want to define a class for your data if you code a reusable class library though. However, tuple is great in presentation layer.

Tien Dinh
  • 1,037
  • 7
  • 12