Sunday, 22 April 2012

Actions and Funcs (part 3).....Func as Selector

Hello again.
This post is the third in my exploration of the usage of Actions and Funcs in building more expressive syntax for libraries.  So far, the posts in this series are:

1. Actions and Funcs.....Intro
2. Actions and Funcs (part 2).....Actions as Builder

So, another cool simple usage of Funcs when designing an API are as a selector.  Funcs provide a nice way to select one of many options while still providing a smart default.  So lets jump into some code:

The small console program above shows a selection of an enum (Color) for a Brush.  You can see in the ChooseColor method we send in Color.Yellow as the default.  This allows us to select the input parameter itself as the Color with the first selection line brush.ChooseColor(c => c);. In the second selection line brush.ChooseColor(c => Color.Red);, the Color.Red is selected. As expected, this program outputs:

Choose Default: Yellow Color Selected: Red Press <enter> to close.

When seeing code like this for the first time, I was confused. I thought, "What exactly is returning a value?". Then I found out a cool piece of syntactic sugar built into Func<T, T>. Basically, if the implementation of the Func<T, T> is a single line (so what is on the right-hand side of the => operator), the compiler will place a return before the code for you. So after compiling brush.ChooseColor(c => Color.Red); becomes brush.ChooseColor(c => { return Color.Red });. This allows for much cleaner and expressive code for examples like this. By the way, if you want a multi-line Func<T, T> then it will require the curly braces.

Well, that is about all I have this time. I think this is a cool little example of where Func<T, T> can make code expressive in a different way and might provide another option when designing a class that selects a value type like Color. Hope this helps.

Tuesday, 10 April 2012

Actions and Funcs (part 2).....Action as Builder

Following on from my last post about Actions, Predicates, and Funcs; I want to provide an example of one place that I've seen a framework successfully use an Action as in an API.  Recently, I've been doing some work with NServiceBus (NSB).  NSB gives a nice terse way to Send or Publish a new message.  It looks like this:

This code uses an Action<T> underneath to create a new instance of the type that is going to be sent or published.  What is extra cool about this is that NSB allows you to define values for properties of an instance that it will dynamically generate.  Like the example above, this allows NSB to give the impression that it can assign values directory to interface properties!

So, how can we allow users of our API to define properties, but keep hold of the specifics about how we create an object?

Action<T> as Builder
Like NSB, we can take in an Action<T> and allow the user of the API to build the object they desire.  To show the specifics of how to do this, I'll complete a non-production version of what NSB does.  So, first we need to define the IBus interface:

And this is a simple implementation for IBus:

A bit of explanation
So, it turns out that the code is quite simple for a pretty cool API feature.  The implementation of IBus only needs to understand the type of the message, then can create a blank instance, and pass the instance to the action for building.  At this point, the action implementation (defined in the method call to IBus.Publish<T>) takes over and fills in all the properties.  This works because T has to be an IMessage (which means it must be a reference type). Nice.  Using this type of technique would also allow the framework code to make a default instance (with some properties set) and let these values to be changed during the action implementation.

More to come...