Adding deconstructors to C# types

Earlier this year, I wrote about being able to deconstruct tuples in C#, something that was added to C# 7. That kind of functional behavior is one of the (so so very few) things I miss from my years of writing Erlang code. It neatens up your code a bit, and you can read more about it here:

Using Tuples and deconstruction to return multiple values in C#

I got to thinking recently though - besides Tuples, is there anywhere else we can use this concept? The answer’s yes, we can define our own deconstruction logic in the classes we create, but now the question is… is it worth it?

The code in this post is available on GitHub, for you to use, expand upon, or just follow along while you read… and hopefully discover something new!

Can we deconstruct our own types?

Microsoft has their own example, using employees, so we’ll do something a little different… okay, maybe not that different. Here’s a simple Country class that can hold a collection of States. Add a simple Deconstruct method and voila - we can extract a couple values, like “name” and “population”.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

public class Country
{
    public string Name { get; set; }
    public List<State> States { get; set; } = new List<State>();
    public long TotalPopulation => States.Sum(s => s.Population);

    /// <summary>
    /// Returns the name and population of the country.
    /// </summary>
    /// <param name="name">Name</param>
    /// <param name="pop">Population</param>
    public void Deconstruct(out string name, out long pop)
    {
        name = Name;
        pop = States.Sum(s => s.Population);
    }

    /// <summary>
    /// Returns the name, population, and number of states.
    /// </summary>
    /// <param name="name">Name</param>
    /// <param name="pop">Population</param>
    /// <param name="numberOfStates">Number of states</param>
    public void Deconstruct(out string name, out long pop, out int numberOfStates)
    {
        name = Name;
        pop = States.Sum(s => s.Population);
        numberOfStates = States.Count;
    }
}

public class State
{
    public string Name { get; set; }
    public long Population { get; set; }
}

/***********************/

using DeconstructUserDefinedTypes;

var usa = new Country { Name = "United States" };
usa.States.Add(new State { Name = "Utah", Population = 3380800 });
usa.States.Add(new State { Name = "Maine", Population = 1385340 });
usa.States.Add(new State { Name = "Florida", Population = 22244823 });

var (name, population) = usa;

Console.WriteLine($"{name} has {population} people in it.");
// United States has 27010963 people in it.

Right out the gate, I see some deal-breakers. Even if the Deconstruct method has comments on it, they don’t show up when you attempt to deconstruct an instance. Hovering over the name where you instantiated the class shows nothing useful. In fact, you don’t even know whether there is a Deconstruct method on a class, or whether there’s 5 or 50 overloads of it, without delving into the class itself.

It’s far more useful to call the Deconstruct method directly, but then it’s just like any other public method with a couple “out” variables, so… nothing special there.

A

There’s absolutely nothing here that performs better or is easier to use than just accessing the properties themselves:

1

Console.WriteLine($"{usa.Name} has {usa.TotalPopulation} people in it.");

So that begs the question, is there a good reason to use these? Or are they only available because of the way they were implemented for Tuples?

Can we deconstruct built-in types?

Where I think they might be more helpful is in the use of extension methods on built-in types that we already know and are relatively simple to understand. Take the Point and Size structs, for example. Let’s write a couple extension methods that add a “Deconstruct” method to each of those:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

public static class ExtendedPoint
{
    public static void Deconstruct(this Point p, out int x, out int y)
    {
        x = p.X;
        y = p.Y;
    }
}

public static class ExtendedSize
{
    public static void Deconstruct(this Size s, out int w, out int h)
    {
        w = s.Width;
        h = s.Height;
    }
}

And then a Furniture class, that’s maybe part of a home design app or something, and it has a size and location within the house.

1
2
3
4
5
6

internal class Furniture
{
    public string Name { get; set; }
    public Point Location { get; set; }
    public Size Size { get; set; }
}

If we define a couch (for example) with a given location and size, we can quickly deconstruct those values later on when we need them.

1
2
3
4
5
6
7
8
9

var couch = new Furniture
{
    Name = "Couch",
    Location = new Point(3, 4),
    Size = new Size(6, 2)
};

var (x, y) = couch.Location;
var (width, height) = couch.Size;

I feel like this works better, because the first thing I’d assume to get from a Point is the x and y coordinates, and from a Size its width and height. It seems slightly more streamlined than doing couch.Location.X and couch.Location.Y.

On a side note, gotta say I’m impressed with VS 2022. As I created the Deconstruct method for this example, it correctly guessed that I’d want to set w to the width of the Size object and h to its height. Magic. 🪄

What do you think? Will you use deconstructors? Do you have your own ideas of how and when to implement them?

If you found this content useful, and want to learn more about a variety of C# features, check out this GitHub repo, where you’ll find links to plenty more blog posts and practical examples!