As much as I love Tuples for rapid prototyping, I am definitely concerned about the long term readability and maintainability vs. using traditional objects in production software. For instance, it can be difficult to determine what a List<Tuple<string, string, string>> collection actually represents compared to a List<ProductInfo> where ProductInfo is an object with 3 string properties with useful names (ItemNumber, ProductName, Price). Thoughts?
After working for a while in Python I found myself doing the same thing, but the first-class handling for tuples in Python makes all the difference.<p>In C#, if the lifetime of your throwaway data structure is very short and tightly scoped (i.e. you only use it inside of one method), you could use an anonymous type. If it's not, I usually find that it's worth it to define a class. Since you're in prototype mode, don't get caught up early on in concerns about good object-oriented design - often I'll just plunk out a class with public fields for use as a data structure and move on.<p>Also, if immutability is the thing that's important to you, often in the prototype phase (especially when you're the only one working on the code) it's good enough to simply keep in mind that you shouldn't be mutating state. You can always come back later and define full constructors, put "readonly" on members, and upgrade fields to Properties and fix the rest of the code with refactoring tools or a quick find/replace.
In my opinion, as such things typically go, it depends on the scope of your tuple usage: I think tuples are perfectly readable/maintainable when used within the context of a single class. It's that middle point between usage within a single method (anonymous types) and usage in the external API (model classes).<p>I try not to leak Tuples between classes: it's easy enough in the API for your class to "unsplat" your tuple usage in any method calls other classes might need.<p>Also, Tuples are likely to become even easier to read/maintain in C#7 or so, as F#-like syntax for Tuples is a strongly favored proposal: <a href="https://github.com/dotnet/roslyn/issues/347" rel="nofollow">https://github.com/dotnet/roslyn/issues/347</a>
I avoid the use of tuples outside of the scope of a function for the reasons you described. I prefer to define a type, even if that type is private to the containing class. Within a function, I prefer to use anonymous classes because of the improved code readability.
I love to use tuples for rapid prototyping too. But when I need the same tuple again on some another place I do refactor my code to use Class instead of tuple.