3

C# 7 has a nice new language feature: The Deconstructor. It is possible to use it for value tuples for instance. However, I can also create my own deconstructors for my own classes. Why would I do that? My classes have properties. So individual items can be accessed anyway.

1
  • 2
    Convenience, and possible future use in pattern matching
    – pmf
    May 13, 2017 at 22:21

2 Answers 2

5

Deconstruction offers considerable brevity and clarity over the traditional alternative, and provides support for a fully functional-style of programming.

Consider this simple, one-line deconstructor example from Microsoft:

var (first, middle, last) = LookupName(id1); 

To do the same thing in the traditional object-oriented way, you would have to write code that looks something like this:

class Name
{
    public string First { get; set; }
    public string Middle { get; set; }
    public string Last { get; set; }
}

var name = someObject.LookupName(id1);

var first = name.First;
var middle = name.Middle;
var last = name.Last;

Even if you returned a tuple, it would still take 4 lines of code, and you would lose your property name mapping:

var name = someObject.LookupName(id1);

var first = name.Item1;
var middle = name.Item2;
var last = name.Item3;
4
  • 1
    Why witte "var first = name.First". You can just use "name.First". Less lines of code and no deconstructors needed.
    – Daan
    May 14, 2017 at 8:11
  • 1
    @Daan Sure, but what if your logic is more complex? How about var family, given; if (user.Culture.FamilyNameFirst) { (family, given) = user.Name; } else { (given, family) = user.Name; }?
    – Jules
    May 14, 2017 at 10:42
  • 1
    @Jules: Unless there is something I'm missing, aren't you better off defining such logic in the Name property itself? It seems weird to put the "logic of the order" outside of the class that returns items in a given order.
    – Flater
    May 18, 2017 at 13:57
  • The downside (or risk) is that something could get deconstructed (and/or deleted) that wasn't intended. I think if objects have references to other objects, there may be a need for this (similar to database cases where there are foreign keys in a table) Oct 3, 2018 at 18:48
2

"Use cases" is a slightly strange verbiage for the question. This doesn't really allow you to do anything you couldn't before. It's simply neater in some cases.

The only major thing I can think of is that it gives you some limited compile-time checking. For example, suppose you have a UsAddress class. You have line 1, line 2, city, state, and zip. You can deconstruct into variables var (line1, line2, city, state, zip) = ObtainAddress(). Now suppose you want to add a line 3. This spot will now be a compilation error because it doesn't match the deconstructor and you can evaluate what you need to do about line 3 at every call site. The alternative would be:

var address = ObtainAddress();
var line1 = address.Line1;
// ...

In this case, there would be no compilation error for the new field. Whether that's good or not is, of course, its own debate.

A lot of the ideas that went into C# 6 and 7 were polishing and easing pain points and it seems like a lot of people complained about the lack of first-class support for tuples in the language. So it isn't so much "use case" as it is syntactic sugar.

1
  • 1
    Of course if you don't want a compile error when the number of fields changes, you can add an overload to continue providing the old version.
    – Jules
    May 15, 2017 at 21:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.