Tuesday, August 24, 2010

Enter F#... An object oriented introduction to a functional language!

Welcome to the very first F# post on my blog.
I thought hard about an appropriate introduction post into the world of F#; and indeed many ideas came to mind. I could blog about currying, function composition, lazy evaluation, and all the other (for many a c# programmer) mystical and ambiguous concepts of functional programming.
Instead, I opted to introduce F# using the decorator pattern example from my previous blog. I thought it would be a nice ice breaker for the uninitiated in functional languages and for those of us, mostly OO practitioners and programmers, who may actually appreciate F#’s ability to be very terse and expressive when it comes to writing object oriented code.
Before presenting the F# version of the query wrappers, I will very briefly cover some key syntactical concepts to help you read the code in this post.
Code Formatting and Indentation:
Something to note about F#, is that it is sensitive to code indentation and line breaks, so indenting the code is not an aesthetic imperative for code readability, it actually is required to compile the code correctly. For a list of F# coding standard please refer to this msdn article
“let” Bindings
The let keyword is used to associate an identifier with a value or a function. Very simple, but powerful. Here are a few examples:
let simpleFloatValue = 1.0f let squaredFunction x = x * x //let is also used inside type constructors type Someclass(name:string) = let _name = name member this.GetName = name.ToUpper()

Type Annotation:
In F#, variables’ types are implicitly inferred at compile time. Optionally, we can provide explicit parameter type. So the following two declarations are identical:


let Adder x y = x + y let Adder (x:int) (y:int) : int = x + y

Generics:
Here are few examples of how F# supports generics. The first two lists are of type int and string respectively. The third example, is a generic function of type T.

let myIntList : int list = [1; 2; 3]; let myStringList : List<string> = ["1"; "2"; "3"]; let myFunction<'T> (t: 'T) : unit = printf " value of generic parameter is: %A" t;

Unit Type:
In F# the unit type represents the absence of a specific value. So for expressions that do not evaluate to a value, the return type is said to be of type unit. The equivalent concept in C# or C++ is the void type.

Pipeline Operator “|>”:
Pipelining enables to write a chain of function calls, such that the output of one function is the input to the following one. This successive call chain is referred to as function pipelining. So the result of the following call chain will be 101. 10 passed to the squared function (becomes 100) and then passed to the incremented function to become 101.

let squared x = x * x let increment x = x + 1 let result = 10 |> squared |> increment

Query Wrappers a la F#:
With no further ado, I list here the F# replica of the C# example included in the previous post. Please note here, that I did not use LINQ query, instead I used simple lists. Fist some data setup, a dummy list of 5 employees:

type Employee = { Name : string; Age : int; IsManager : bool} let emp1:Employee = {Name = "emp1"; Age = 25; IsManager = false}; let emp2:Employee = {Name = "emp2"; Age = 50; IsManager = true}; let emp3:Employee = {Name = "emp3"; Age = 42; IsManager = false}; let emp4:Employee = {Name = "emp4"; Age = 31; IsManager = false}; let emp5:Employee = {Name = "emp5"; Age = 37; IsManager = true}; let employees = [emp1;emp2;emp3;emp4;emp5];

And then the abstractions and the query wrappers.

[<AbstractClass>] type QueryComponent<'T>() = abstract member Query : unit -> 'T list [<AbstractClass>] type QueryWrapper<'T>(qc:QueryComponent<'T>) = inherit QueryComponent<'T>() let _component = qc member self.CallTrailer : 'T list = _component.Query() type EmployeeQuery() = inherit QueryComponent<Employee>() override self.Query() = employees type ManagersQuery(qc) = inherit QueryWrapper<Employee>(qc) override self.Query() = base.CallTrailer |> List.filter (fun e -> e.IsManager) type EmployeeAgeQuery(qc, age) = inherit QueryWrapper<Employee>(qc) override self.Query() = base.CallTrailer |> List.filter (fun e -> e.Age > age)

That’s basically it!! To test the code, use the F# interactive tool in visual studio. Here are a couple of examples to try:

//Get All Managers let managers = ManagersQuery(EmployeeQuery()).Query(); //Get All Employees Older Than 35 let employeesOlderThan35 = EmployeeAgeQuery(EmployeeQuery(), 35).Query()

The results of running the aforementioned two queries will return respectively, the following:

val managers : Employee list = [{Name = "emp2"; Age = 50; IsManager = true;}; {Name = "emp5"; Age = 37; IsManager = true;}] val employeesOlderThan35 : Employee list = [{Name = "emp2"; Age = 50; IsManager = true;}; {Name = "emp3"; Age = 42; IsManager = false;}; {Name = "emp5"; Age = 37; IsManager = true;}]


Recap:
Again I fully realize that such an example is probably not the best introduction into the world of functional programming but let it serve as an prelude for what is yet to come. The following Blog post will solve the same problem using purely functional approach exposing more of the interesting features of F#.

Enjoy the #-ness!

Wednesday, June 23, 2010

Design Patterns Part I :: Composed LINQ queries using the Decorator Pattern

This Blogs series will explore practical uses and applications of design patterns in day to day development practices, using practical examples in C#. The first Blog (one of hopefully many more to come) will cover the Decorator Pattern.

Introduction and Concepts

Let’s kick off this post with some theory. According to the GoF, the intent of the decorator design pattern is to
“Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality”
That was quoted from their seminal work Design Patterns: Elements of Reusable Object-Oriented Software

In my humble opinion, one of the greatest pleasures working in software development is when we can successfully implement a pattern, not through a premeditated intent but through natural and organic development of the code at hand. We spot the variation and try to encapsulate it and then lo and behold we end up using one pattern or another fulfilling its intent and purpose. I think a the holy grail of OO software developers (a slightly conceited statement perhaps) is to identify the what is common and what varies in any given requirement and then find a way to encapsulate that change making future (and almost inevitable requirement changes) relatively easy to implement.

After that brief techno-rant. We can go back to our main topic. The Decorator Design Pattern. Conceptually, here is how the pattern looks like:


The decorator pattern allows me to create a chain of objects (trail of decorator objects) namely, the decorators that are responsible for the new functionality, and ends with the original object. And the call chain looks like:



This is not to be confused with a linked list. Rather it should be regarded as a collection of optional decorating objects.

One classic example of this pattern is the stream I/O library. For any particular stream there is only one input, but there can zero or more actions to perform on the input stream. For instance, as in the example below, I can read from a memory stream, filter the stream and then read it using a custom stream reader. All these components (the later two are custom objects) implement the stream abstract class and accept a stream object in their constructors. the chain of calls looks like this:


Stream filteredMemoryStream =
                new StreamReader(new StreamFilter(new MemoryStream()));

Query Decorators


Personally, I use the decorator pattern to solve the problem of decomposing LINQ queries into more granular and reusable parts. A client can call several LINQ queries that are similar but only have minor variations. The direct result of this is LINQ code duplicated in every query. Another side effect is the tight coupling between the calling client and query composition.

The fictitious example I use here assumes we're querying an Employees repository and there are multitude of queries that might contain the same expressions and clauses. Say, we need to get all employees who are managers. Another requirement is what we get all employees who are managers and of certain age. We may then need to get the top %20 of those managers. All these extra queries are transformed into reusable decorators as follows:



As a direct result of this design, the query composition can be chained inside a factory that instantiates the desired query based on simple conditional logic of perhaps some configuration file:


public class EmployeeQueryFactory
{
    public static QueryComponent<Employee> GetQuery()
    {
        /*
         * We decouple the calling client from the query component instantiation
         * by using this factory method where we encapsulate all conditional
         * logic that determines which query component to instantiate
         * */

        //Get all employees who are contractees
        return new ContracteesQuery(new EmployeeQuery());

        //Get all managers older than 50
        return new AgeLimitQuery(new ManagersQuery(new EmployeeQuery()), 50);

        //Get top %20 of all contractees older than 30
        return new Top20PercentQuery(new AgeLimitQuery(new ContracteesQuery(new EmployeeQuery()), 30));
    }
}


And just to add more clarity to the example at hand, I add a simple implementation of the QueryComponent and QueryWrapper respectively, along with a concrete implementation of each.

public abstract class QueryComponent<T>
{
    public abstract IQueryable<T> Query();
}


public class EmployeeQuery : QueryComponent<Employee>
{
    public override IQueryable<Employee> Query()
    {
        return new EmployeesRepository().GetAllEmployess().AsQueryable();
    }
}


public abstract class QueryWrapper<T> : QueryComponent<T>
{
    protected readonly QueryComponent<T> QueryComponent;

    protected QueryWrapper(QueryComponent<T> queryComponent)
    {
        QueryComponent = queryComponent;
    }


    protected IQueryable<T> CallTrailer()
    {
        return null != QueryComponent ? QueryComponent.Query() : null;
    }
}


public class ContracteesQuery : QueryWrapper<Employee>
{
    public ContracteesQuery(QueryComponent<Employee> queryComponent)
        : base(queryComponent)
    {
    }


    public override IQueryable<Employee> Query()
    {
        return CallTrailer().Where(p => p.IsContractee);
    }
}

Lastly, as with every post. I leave you with this quote by Christopher Alexander
"We are searching for some kind of harmony between two intangibles: a form which we have not yet designed and a context which we cannot properly describe."

Code well and Stay#!

Friday, June 4, 2010

The Daily WTF

Greetings All Code Monkeys...

For those of us who have been subjected to unforgettable code atrocities, or for those who would like to seek solace in other people's horrendous coding errors (to feel better about their own!) - yes we all are red handed when it comes to writing code that should never have seen the light of day.

Check the The Daily WTF gives you the fix.I love that web site.

Friday, May 21, 2010

Developer Tunnel Vision Syndrome

I wanted my very first post to be on a rather happier note that celebrates the beauty of learning functional programming with F#, or touts a technical triumph or a breakthrough of mine. But the post is going to be more sombre and talk about Developer Tunnel Vision; a syndrome I have been suffering from over the past couple of days until the eventual breakthrough this morning.

I say Tunnel Vision, because developers often spend inordinate amounts of time working exclusively in one technology or one programming language (C# for argument’s sake) and forget to touch on some neglected skills like thinking in T-SQL and finding solutions using solely set algebra and set operations.

To give you a concrete example, I present the problem I had (with contrived data for demonstration purposes): given a list of values (say, velocities) with start/end time range for each velocity; in tabular form the input data looks like:

Velocity    StartTime               EndTime     
--------    -------------------     -------------------
40
         2009-11-24 05:45:43     2009-11-25 04:23:18
0           2009-11-25 04:23:18     2009-11-26 07:00:00
0           2009-11-26 07:00:00     2009-11-27 06:23:18
40          2009-11-27 06:23:18     2009-11-27 23:57:22
0           2009-11-27 23:57:22     2009-11-28 09:00:00
0           2009-11-28 09:00:00     2009-11-30 01:57:22
0           2009-11-30 01:57:22     2009-11-30 11:00:00
0           2009-11-30 11:00:00     2009-12-02 03:57:22
0           2009-12-02 03:57:22     2009-12-04 05:57:22
40          2009-12-04 05:57:22     2009-12-04 15:45:43


Using only plain set operations in T-SQL, collapse date ranges for matching velocities, to produce the following:

Velocity    StartTime               EndTime       
--------    -------------------     -------------------
40          2009-11-24 05:45:43     2009-11-25 04:23:18
0           2009-11-25 04:23:18     2009-11-27 06:23:18
40          2009-11-27 06:23:18     2009-11-27 23:57:22
0           2009-11-27 23:57:22     2009-12-04 05:57:22
40          2009-12-04 05:57:22     2009-12-04 15:45:43

Simple at the first glance! So I went forward equipped with what I considered a solid knowledge in SQL and set algebra and started working on the solution.

I was amazed at how difficult it was, because I recently had spent the good part of the past year or so thinking exclusively in Object Oriented way and I felt my mind struggled to rid itself of inheritance and polymorphism and to think in joins and unions. I eventually got to the answer, not the most elegant or succinct, but a good answer nonetheless (it is irrelevant to post the solution here).

This morning however, I recanted yesterday’s solution and came up with a 3-line C# LINQ query that produced exactly the desired result.

var collapsedRecords = records
                .Aggregate(new List<Record>(), groupingFunctor)
                .GroupBy(dco => dco.GroupId, (k, v) => v)
                .Select(v => new Record
                                 {
                                     Velocity = v.First().Velocity,
                                     ST = v.Min(_ => _.ST),
                                     ET = v.Max(_ => _.ET)
                                 });

Along with the following simple plumbing:




Func<List<Record>, Record, List<Record>> groupingFunctor =
                (list, record) =>
                    {
                        record.GroupId = !list.Any() ? 1 :
                                        ((list.Last().Velocity == record.Velocity)
                                                 ? list.Last().GroupId
                                                 : list.Last().GroupId + 1);
                        list.Add(record);
                        return list;
                    };

And

    //simple model for the records
    internal class Record
    {
        public int Velocity { get; set; }
        public int GroupId { get; set; } //helper property
        public DateTime ST { get; set; }
        public DateTime ET { get; set; }
    }

Now we can digress and start raving about the accumulator pattern in the LINQ Aggregate extension method, or we can get to the point of this post:

Most of us juggle more than one language and/or technology. And in order to stay sharp (no pun intended!) we must practice, practice and then practice some more lest time and negligence dulls the edge of our skills.

Finally, I leave you with a bit of Charles Darwin:
"I have steadily endeavored to keep my mind free so as to give up any hypothesis, however much beloved (and I cannot resist forming one on every subject), as soon as the facts are shown to be opposed to it."