Here at TrueNorth we love functional programming and if you code in this style you will end up using lots of tuples, and tuples of tuples and…. you get the idea.

A lot of bread and butter business software coding is just manipulating sets of data, grouping, selecting, filtering, joining etc… Often whilst transforming your inputs to your outputs there will be some intermediary structures involved.

There are a few options for representing these structures:

Wrapper classes
Pros: readable, can be passed around, logic can be encapsulated in your class
Cons: Lots of boilerplate, clutters up your schema for throwaway classes, hides the logical structure if just wrapping other data structures for processing

Anonymous classes
Pros: named values, no boilerplate, schema is kept clean
Cons: Can’t be passed around, type inference fails too often

Pros: No boiler plate, schema is kept clean, can be passed around
Cons: No named values can get very confusing!

Personally, I tend to use Tuples if the situation does not warrant a full blown wrapper class, however things can get confusing.

Here’s an example of a return type signature for a private method I was working on the other day:

 private Dictionary<DateTime,
               Dictionary<Tuple<int, Guid>, 
                   Dictionary<Guid, int>>> getProviderCounts(IEnumerable<DateTime> cutOffDates)

Basically we needed to take a date, and for each one produce a lookup from an (int,Guid) pair to another lookup from a Guid to an int. Easy to get confused what all these refer to! We can use the concept of ‘Tiny Types’ or ‘Micro Types’ here to make things more readable:

‘Tiny Types’ is the idea of wrapping all primitives in simple wrapper types with a number advantages but I’m going to focus on readability of Tuples.

Let’s define a TinyType base class to make the syntax for this as easy as possible:

public abstract class TinyType<T>
    public TinyType() { }
    public TinyType(T value)
        this.Value = value;

    public T Value { get; set; }

    /* standard GetHashCode & Equals overrides */


We can now rewrite our method as follows:

 private class CutOffDate : TinyType<DateTime> { };
 private class CustomerGroup : TinyType<int> { };
 private class CustomerType : TinyType<Guid> { };
 private class Provider : TinyType<Guid> { };
 private class ProviderCount : TinyType<int> { };

 private Dictionary<CutOffDate, 
              Dictionary<Tuple<CustomerGroup, CustomerType>, 
                     Dictionary<Provider, ProviderCount>>> getProviderCounts(IEnumerable<CutOffDate> cutOffDates)
           var date = new CutOffDate() { Value = DateTime.Now };
           var group = new CustomerGroup() { Value = 7 };
           /* etc */

Which is a lot clearer and safer when using the data structure returned by this method.

5 thoughts on “An adventure with Tiny Types and Tuples

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s